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!!
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.
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, leonhart.me88@nctu.edu.tw, in case that you don't want to public your contact info.
Thanks.
(@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.
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.
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.
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.
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.
Quote