1

私の会社では、Windows XP で動作する MFC アプリケーションを構築しています。ユーザーがログ ファイルを保存できるようにコモン ファイル ダイアログを開くと、このアプリケーションでクラッシュが発生するという報告が、お客様の 1 人から報告されています。

どの統合システムでも、このクラッシュは確認されていません。顧客は、プログラムがアドレス 160b2d48 でアクセスできないメモリから読み取ろうとしていることを示すクラッシュ ダンプを提供してくれました。アドレスは、そのすぐ上と下にロードされた DLL (15dc0000-16085000 および 160c0000-1611b000) があるため、アドレス空間のコード セクションからのもののように見えますが、そのアドレスには何もロードされていません。クラッシュしたスレッドのスタックは次のとおりです。

>   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

このスタックにはアプリケーションからのコードはなく、上記の証拠と組み合わせると、アプリケーションが [保存] ダイアログを表示するときにシェル拡張機能 (スタック トレースを考えると、おそらく情報ヒント ハンドラー) が呼び出されるためにクラッシュが発生するのではないかと思いますが、何らかの理由でプロセスに読み込まれません。

  • 私の仮説は妥当ですか？
  • もしそうなら、責任のあるシェル拡張を追跡するにはどうすればよいですか?
4

2 に答える 2

3

はい、シェル拡張やその他のシステム フック DLL は、プロセス空間内で効果的に実行されます。多くの場合、ファイルを開くダイアログを表示するときに、アプリケーションがクラッシュする原因となった多くの拡張 dll でこれが発生することがわかりました。クラッシュ ダンプがある場合は、windbgロードされているすべての dll を調べます。マイクロソフトのものは無視してください。残っているものには犯人が含まれています。または、顧客にAutorunsを実行するよう依頼し、.arn ファイルを保存して送信します。AppInit と Explorer は、確認するタブです。

于 2011-10-14T14:42:18.700 に答える
0

このようなクラッシュの理由の1つは、スタックオーバーフローです。シェル拡張機能はファイルを開く/保存ダイアログに読み込まれ、それらの拡張機能もスタックスペースを消費するため、アプリにそれに対応するのに十分なスタックスペースが残っていることを確認する必要があります。

したがって、プロセスのスタックサイズを増やすか、ファイルを開く/保存ダイアログを呼び出す関数のスタック使用を減らします。

これではこのクラッシュは修正されない可能性がありますが、クラッシュの考えられる理由の1つです。

于 2011-10-14T15:48:06.457 に答える