问题
My company builds an MFC application that runs on Windows XP. One of our customers has reported a crash in this application that occurs when it opens a Common File Dialog to allow the user to save a log file.
We haven't observed this crash on any of our integration systems. The customer provided us with a crash dump which shows that the program is trying to read from some inaccessible memory at address 160b2d48. The address appears to be from the code section of the address space, as there are DLLs loaded just above and below it (15dc0000-16085000 and 160c0000-1611b000), but nothing is loaded at that address. The stack of the crashing thread is as follows:
> shell32.dll!CFSFolder::GetDetailsEx() + 0x533c8 bytes
shell32.dll!CInfoTip::_GetInfoTipFromItem() + 0x169 bytes
shell32.dll!CInfoTip::GetInfoTip() + 0x1c bytes
shell32.dll!CFolderInfoTip::GetInfoTip() + 0x95 bytes
shell32.dll!CStatusBarAndInfoTipTask::RunInitRT() + 0xf5 bytes
shell32.dll!CRunnableTask::Run() + 0x4c bytes
browseui.dll!CShellTaskScheduler_ThreadProc() + 0x82 bytes
shlwapi.dll!ExecuteWorkItem() + 0x1d bytes
ntdll.dll!_RtlpWorkerCallout@16() + 0x65 bytes
ntdll.dll!_RtlpExecuteWorkerRequest@12() + 0x1a bytes
ntdll.dll!_RtlpApcCallout@16() + 0x11 bytes
ntdll.dll!_RtlpWorkerThread@4() + 0x1794c bytes
kernel32.dll!_BaseThreadStart@8() + 0x37 bytes
There is no code from our application on this stack, and paired with the above evidence, I suspect the crash happens because a shell extension (probably an info tip handler, given the stack trace) is called when our application shows the Save dialog, but isn't loaded in the process for some reason.
- Is my hypothesis reasonable?
- If so, how should I go about tracking down the responsible shell extension?
回答1:
Yes, shell extensions and other system hook dlls effectively run within your process space. I've found this to happen with a number of extension dlls that have caused our application to crash, often when showing a file open dialog. If you have the crash dump in windbg
then take a look at all the dlls that are loaded. Ignore any Microsoft ones, and whatever's left will contain the culprit. Alternatively ask the customer to run Autoruns, Save the .arn file and send it to you. AppInit and Explorer are the tabs to check.
回答2:
One reason for such crashes are stack overflows. Since shell extensions are loaded in the file-open/save dialogs, and those extensions use up stack space as well, you have to make sure your app has enough stack space left to accommodate for that.
So either increase the stack size of your process, or reduce the stack use of the function where you call the file-open/save dialog.
This might not fix this crash, but it's one of the possible reasons for crashes.
来源:https://stackoverflow.com/questions/7769156/could-a-shell-extension-be-causing-my-program-to-crash