Manage not working

leonwu · 09 Oct 2009

Hi,

I occur a problem that when i right click on "Computer" and click "Manage", it does nothing.
Just like this thread, Computer Context menu - Manage not working
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 · 09 Oct 2009

What is your application?

leonwu · 10 Oct 2009

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 · 10 Oct 2009

leonwu said:

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 · 11 Oct 2009

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 · 11 Oct 2009

leonwu said:

...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 · 12 Oct 2009

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 · 12 Oct 2009

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

H2SO4 · 12 Oct 2009

leonwu said:

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

Computer Context menu - Manage not working

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 · 12 Oct 2009

swarfega said:

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.