Fixed ADPlus That Works with Windows 7 (and Probably S2K8 R2)

Edit Feb. 20, 2009: Note that Microsoft has fixed ADPlus with the 6.11.1.402 version of the Debugging Tools for Windows. Use that version instead of my version posted here.

Windows 7 has been working quite well for me and the new taskbar is completely fantastic. Being that it’s in beta there are a few bugs I’ve run into here and there. The worst bug is that if I’ve logged my laptop into my domain, Explorer hangs when accessing the C: drive. Fortunately, it’s a very rare bug so it has been hard to reproduce, but when it happened this morning, I flipped over to PowerShell and ran ADPlus to grab a mini dump of the Explorer process so I could include the mini dump with bug report.

If you’re not familiar with ADPlus, you should be. It’s a wonderful VBScript program that allows you to build a script for CDB the console version of WinDBG. With ADPlus, you can grab mini dumps of a process at any time, which is a hang mode attach. Additionally, you can attach in crash mode, which allows you to set breakpoints or specific exception processing to get mini dumps and logging exactly when need it. ADPlus is the tool for dealing with production problems. For more information on ADPlus, read the documentation, or see my book, Debugging .NET 2.0 Applications.

Running ADPlus in hang mode and the –pn (process name switch) to get the dump of the hung Explorer process, showed something disturbing:

>adplus -hang -pn explorer.exe -o c:junk
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

The following requested processes are not executing:
EXPLORER.EXE;

If Explorer isn’t running, there’s not a whole lot you can do with a Windows machine! While I was definitely looking at the hung Explorer, I thought maybe there was a hidden instance or something that wasn’t allowing me to attach to the correct Explorer process. Using Process Explorer, I got the process ID of the hanging Explorer window and ran my ADPlus command again with the –p switch to specify the exact instance I wanted the mini dump.

>adplus -hang –p 2756 -o c:junk
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

The following requested processes are not executing:
2756;

As I had the Debugging Tools for Windows package version 6.10.2.233 on Windows 7 and a Windows Vista machine, I tried the same commands on Vista and, of course, ADPlus found the process in both cases and produced great mini dumps. It didn’t take a rocket scientist to figure that something was different on Windows 7.

Having used ADPlus for many years, I knew that ADPlus found processes by running TLIST.EXE, which is part the Debugging Tools for Windows installation. ADPlus saves the output of running TLIST.EXE in the Hang_* output directory in Process_List.txt.

Comparing the Vista version and the Windows 7 versions of Process_List.txt it was blindingly obvious what was wrong. On Vista, the output looked like the following for all processes:

1 32 488 csrss.exe Title:
Command Line:
0 32 532 services.exe
Command Line:
1 32 564 winlogon.exe
Command Line:

The first number is the windows session, the second is the bit-ness level, and the third is the process ID.

On Windows 7, the same version of TLIST.EXE showed the following for interactive processes (interestingly, non interactive processes are reported with the same as Vista):

[0] 1 32 1360 Test.exe Title:
Command Line: “c:junktest.exe
[0] 1 32 5828 powershell.exe
Command Line: …

Yes, we have an extra “[0] ” on Windows 7. I not sure what the extra value means, because it’s not mentioned in the documentation, but I suspect it might be something to do with a Terminal Server session.

Cracking open ADPlus.vbs, and spending 10 minutes debugging through the Process_List.txt parsing code proved my hypothesis. Three more minutes thinking and I had the fix.

Unfortunately, according to the REDIST.TXT in the Debugging Tools for Windows package, ADPlus is not redistributable so I don’t think I can the complete updated fix. However, it’s simple to tell you how to do the fix on your own. In your favorite text editor, open ADPlus.vbs and verify the VERSION constant at the top of the file is 6.03.004. If it is to line 2,181 and you’ll see the following code.

While not objTextFile.AtEndofStream
strAux = objTextFile.ReadLine
If instr(strAux, “Command Line:”) = 0 then
if PCount > ArraySize Then
ArraySize = ArraySize + 50
Redim Preserve g_CurrentProcesses(ArraySize)
End If
‘ parsing PID, PNAME and PackageName if existing
StrLength = Len(strAux)

Directly after the line “StrLength = Len(strAux)” (line 2,189) add the following:

””””’
‘ Changes by John Robbins to fix the parsing bug.
‘ The bug is that on Win7 and some Vista machines, TLIST.EXE adds
‘ an extra value on the front of the string.
‘ ADPLUS is expecting the string to look like the following:
‘  0 32  532 services.exe
‘ Interactive processes on Win7 look like the following:
‘ [0]  1 32 2756 explorer.exe    Title: Program Manager
‘ To fix the parsing, I need to get rid of that “[0] ” before the
‘ string goes to the rest of the parsing code.
””””’
If Left(strAux,4) = “[0] ” then
‘ Remove those those characters.
strAux = Right(strAux, StrLength – 4)
‘ Update the string length as it’s used below.
StrLength = StrLength – 4
EndIf

Note that Microsoft digitally signed ADPlus.vbs so this addition will mean the digital signature is now invalid. You may want to delete the digital signature in the big comment at the bottom of the file.

Once I added this quick fix for the extra “[0] ” from running TLIST.EXE on Windows 7, ADPlus properly wrote the my mini dump of the hung Explorer process but there was one other issue I ran into, but it was with CDB.

As part of the normal hang mode commands ADPlus has CDB run is “!handle 0 0” which dumps the handle table for the process showing the handle type information. With the Debugging Tools for Windows version 6.10.2.233 on Windows 7, the command goes into an infinite loop. A quick test showed this same problem in WinDBG as DBGENG.DLL does the real work for both debuggers. The good news is that you have two options to get past this hang. If you’re using CDB, you can press CTRL+C and in WinDBG, press CTRL+BREAK, and you will pop out of the stuck loop.

Let’s keep our fingers crossed for an official Debugging Tools for Windows release that will address both these issues. Let me know if you’re having any other issues with ADPlus and I’ll see if I can help you out. Also, if you’re running Windows Server 2008 R2, let me know if the fix for ADPlus works there as well.