Quote: Originally Posted by leonwu
Excuse me, i have not debugged user mode applilcations more than two years....many debug methods I have forgotten. Would you mind telling me more detail?
It's an interesting issue and I'd be quite keen to try to help debug it - but I can't since I don't have a repro
Hence, I've stepped through the basics in the attached debugger log:
- bp <address> to set a breakpoint
- bl to list breakpoints
- g for "go", g @$ra for "go until you hit the return address of the current function"
- r to list registers
- du @rcx, dump memory as a unicode string beginning at RCX offset
... and so on. It's not rocket science but it's not trivial either.
I used kernel32!CreateProcessW as the test breakpoint. Note how the RCX register contains the first function parameter (lpApplicationName), which in this case is MMC.EXE of course. Then I let it complete (g @$ra) and checked that the function return value (in RAX) was non-zero, which indicates success as per the function's MSDN doco.
In your instance it would be interesting to see whether the CreateProcessW breakpoint gets hit at all, and if so what the return value becomes. After that, you might want to use some of the activity you logged in ProcMon as the basis for further breakpoint-based troubleshooting.
If you're feeling a bit rusty with this stuff, it'll be marginally easier on an x86 machine because of the way the STDCALL calling convention places args on the stack, instead of using the registers like x64 does. Otherwise, a "checked" build of x64 Windows (from MSDN) is made up of non-optimised binaries which are going to "spill" args onto the stack, even on x64. It'll be easier to debug than straight, optimised x64 code.
EDIT: For what it's worth, I think the conclusion is wrong in this thread: Computer Context menu - Manage not working
The Windows 7 version of CompMgmtLauncher.exe is not "corrupted". It's just less forgiving in this instance than the Vista build, for reasons which form the crux of this issue. I suspect the poster who came up with the "solution" at the end may have additional info, since he apparently didn't feel compelled to fix the "corrupted" version of the Windows 7 binary by extracting/repairing, but instead went straight for the Vista executable.