Manage not working

[leonwu]

Hi,

I occur a problem that when i right click on "Computer" and click "Manage", it does nothing.
Just like this thread, http://www.sevenforums.com/general-discussion/22522-computer-context-menu-manage-not-working.html
But the difference is our application causes this.
I have tried to replace compmgmtlauncher.exe with vista compmgmtlauncher.exe file as the thread metioned.
It's works, but i don't think it's a good answer for our customer.
Does anyone know why or how our application cause this?? Our application install a context menu on files and folders. And it wouldn't affect "Manage" working on vista.
And i tried to install WinRAR(it also has context menu), "Manage" also works well.

Thanks.

 

[Antman]

What is your application?

 

[leonwu]

It's a fingerprint application. We insert encryption items in context menu. We have no idea why "Manage" would invoke our dll then "Manage" doesn't show up. But we replace the .exe file with vista's, it works well.

Thanks.

 

[H2SO4]

It's a fingerprint application. We insert encryption items in context menu. We have no idea why "Manage" would invoke our dll then "Manage" doesn't show up. But we replace the .exe file with vista's, it works well.

Thanks.

I'm not an authority on licensing, but I'm confident that giving out Vista binaries is against the EULA (unless the customer already owns a Vista license for that machine?). I'm guessing that you're only swapping those executables for test purposes anyway. It's not a good look solution, as you've pointed out.

Unless this is some sort of widespread issue, in which case your web searches would already have found the answer, you'll presumably need to do a bit of code-level analysis. I don't know anything about your personal background, but the developers on the team will be capable of attaching a debugger (WinDBG/CDB/NTSD) to the process and then "stepping" through to see what the deal is with your DLL registered and present. Everything else is just conjecture.

Alternatively, if you can isolate a cut-down version of your app that reliably replicates the issue, and put it up somewhere for download, I or somebody else may be able to tell you what's wrong. No guarantees though.

 

[leonwu]

To replace "Manage" with vista's is the idea from the web i foud, and i don't think it's a good solution as you say. There is one thing confusing me, our application wouldn't affect "Manage" in vista. What is the difference between win7 and vista?? I have tried to use Procmon to see how CompMgmtLauncher.exe would call our dll. There is someting strange, it would do "CreateFile" to mydll.dll.1000.manifest, do "QueryOpen" to mydllENU.dll and do "QueryOpen" to mydllLOC.dll. The result, of course, is "NAME NOT FOUND" because my dll name is mydll. We don't know why "Manage" need to create or query xxx.1000.manifest, xxxENU.dll, and xxxLOC.dll files, and it don't do the same thing to other dll. More information, our dll is no crash or any abnormal states, it loads and unload normally.

Thanks.

 

[H2SO4]

...There is someting strange, it would do "CreateFile" to mydll.dll.1000.manifest, do "QueryOpen" to mydllENU.dll and do "QueryOpen" to mydllLOC.dll. The result, of course, is "NAME NOT FOUND" because my dll name is mydll. We don't know why "Manage" need to create or query xxx.1000.manifest, xxxENU.dll, and xxxLOC.dll files, and it don't do the same thing to other dll. More information, our dll is no crash or any abnormal states, it loads and unload normally.

Thanks.

I don't think that's your problem. It's looking for LOCalised language-specific resource DLLs, first in the form of "US English" (ENU), then as a localised variant. When it fails to find those, it falls back on default resource strings in mydll.dll - assuming they're there.

ProcMon can't show you everything, mostly because it doesn't hook everything. I'd suggest stepping through this in a debugger.

 

[leonwu]

At beginning, i think it may some calling scenario changed so "Manage" works well in vista but not in win7. I think it's another way for me to find this bug out.
There are what i have tried:
1. Insert many messages in many functions in my dll. It seems ok as the message shows. I know it doesn't mean a lot.
2. Using WinDbg "Open Executable" to execute CompMgmtLauncher.exe. It also seems no any errors.
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?

Thanks.

 

[swarfega]

I can confirm that clicking on manage doesnt work for me either. Is it supposed to load the computer management admin tool?

 

[H2SO4]

...
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?

Thanks.

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:

http://www.sevenforums.com/general-discussion/22522-computer-context-menu-manage-not-working-6.html

The Win7 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 Win7 binary by extracting/repairing, but instead went straight for the Vista executable.

 

[H2SO4]

I can confirm that clicking on manage doesnt work for me either. Is it supposed to load the computer management admin tool?

Yes. You'd also have one or more shell extensions which are interfering, for what it's worth. In the OP's case, he already knows it's his own (extension), so getting rid of it is presumably not an option.

 

[leonwu]

Hi, H2SO4
The attachment is our application with context menu only.
Installation steps:
1. Execute InstallContexMenu.exe (run as Admin, x64 only)
2. Press "Install"
If you want to delete the context menu in you computer, pressing "Uninstall".

I follow steps as you say, setting breakpoint on kernel32!CreateProcessW, it wouldn't break into this point. I don't think it calls CreateProcess.
Thanks for your great help!!

 

[H2SO4]

Hi, H2SO4
The attachment is our application with context menu only.

Have a look at the attached log please. The process calls into LTTEncryptMenu.DLL but the results are unsatisfactory, and in turn it doesn't call CreateProcessW to start mmc.exe.

Any chance you could give me some symbols for that binary, even if they're just "public" and devoid of type info? Thanks.

 

[leonwu]

Sure! I can give you the symbol files but some of binary files need to update. I will give you tomorrow morning(all files are in the company).
There is another request, could i have your mail?? I want to know more about these. I leave mine, [email protected], in case that you don't want to public your contact info.
Thanks.

 

[H2SO4]

...
There is another request, could i have your mail?? I want to know more about these.

(@Mods, is there any chance we could move this to the "crashes and debugging" section? TIA)

Nothing personal, but let's keep it on the forum please. I'll do my best to answer any questions about tools and technique, and there's no need to do that in private.

The deviation from norm is most obvious if you place a breakpoint on SHELL32!HDXA_LetHandlerProcessCommandEx. The second time that's hit, DSA_GetItemPtr processing eventually reaches your handler, and at that point the process goes about 4 or 5 calls deep into your code - that's why the symbols would be useful in trying to understand what you're doing without having to go through the rigmarole of disassembling your executable.

If you'd like to watch this, set that SHELL32!HDXA_LetHandlerProcessCommandEx breakpoint, and the second time it's hit use the "trace and watch" command: WT.

In a normal run (without your code), SHELL32!HDXA_LetHandlerProcessCommandEx+0xe1 ends up calling into SHELL32!CRegistryVerbsContextMenu::InvokeCommand to fire up the MMC. However, the presence of your DLL prevents that and HDXA_LetHandlerProcessCommandEx detects an error condition after interacting with your DLL.

 

[leonwu]

OK, I know. Thanks.

The attachment includes 3 binary files and their symbols. I would follow the steps you show me at the same time.

Thanks a lot.

 

[leonwu]

Hi,
The deadline was yesterday so i use a work aroud way to fix it. I return fail while compmgmtlauncher.exe calls DllGetClassObject of my dll. It wouldn't call QueryInterface, GetCommandString...etc, therefore compmgmtlauncher.exe could show up normally.
I will trace this issue and update the lastest status if i find the root cause.

Thanks.

 

[Dilandau]

I've got Windows 7 Pro x64 installed (final), it got the same problem

CompMgmtLauncher.exe doesn't work anymore so I replace the registry key

[HKEY_CLASSES_ROOT\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}\shell\Manage\command]

I wrote "%SystemRoot%\system32\mmc.exe" CompMgmt.msc

instead of %SystemRoot%\system32\CompMgmtLauncher.exe

I'm waiting for a Microsoft fix.

 

[H2SO4]

I've got Windows 7 Pro x64 installed (final), it got the same problem

CompMgmtLauncher.exe doesn't work anymore so I replace the registry key

[HKEY_CLASSES_ROOT\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}\shell\Manage\command]

I wrote "%SystemRoot%\system32\mmc.exe" CompMgmt.msc

instead of %SystemRoot%\system32\CompMgmtLauncher.exe

I'm waiting for a Microsoft fix.

You might wait a while because the problem is caused by add-ons, not by the launcher. Since you're bypassing the launcher and going straight to the snap-in, there's presumably decreased functionality.

 

[Dilandau]

Really ??? Is it Microsoft Security Essentials the problem ?

 

[H2SO4]

Really ??? Is it Microsoft Security Essentials the problem ?

I'm not sure how you came to that conclusion?

Anyway, in the OP's case, the problem was very definitely his Explorer add-on. He knew that even before we started troubleshooting, because removing his add-on made the problem go away. However, being a developer, he didn't have the luxury of just giving up on his component.

The cause will be different on different machines. I'd suggest starting your own thread if you'd like assistance in troubleshooting.