Could a shell extension be causing my program to crash?

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!_Rt开发者_如何转开发lpWorkerCallout@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?

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.

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.