19

私のソフトウェアは最近、アプリケーションが起動直後にクラッシュしたと言う顧客にデプロイされました。最初のデバッグの後、顧客は、アプリケーションを実行できなかったコンピューターの 1 つへのリモート アクセスを提供してくれました。 クラッシュは私のアプリケーションに固有のものではないことがわかりました。.NET フレームワークに依存するアプリケーションは、すぐにクラッシュしました。

便利なことに、Visual Studio 2008 がインストールされていたので、簡単な Hello World アプリケーションを作成し、[デバッグ] をクリックしました。アプリケーションは正常に機能しました。しかし、生成されたバイナリを Visual Studio の外の /bin/Debug/HelloWorld.exe ディレクトリで実行しようとすると、クラッシュしました。

私が試したことのリスト（更新済み）：

  • "Everyone" が c:\Windows の読み取りと実行のアクセス許可を持っていることを確認しました。
  • 問題が (私のアプリケーションではなく) .NET Framework にあることをテストするために、Paint .NET をコンピューターにダウンロードしようとしました。セットアップ フロントエンドも同じようにクラッシュしました。
  • http://support.microsoft.com/kb/908077で概説されているように、.NET フレームワークの修復を実行しました(少年はこれが楽しくて時間がかかりました)。運がない。
  • .NET 3.5 SP1 をインストールしました (.NET 3.5 をインストールする前に) 注: 私のアプリケーションは 2.0 をターゲットにしているので、これはロング ショットとして行いました... しかし、その過程で .NET 3.5 SP1 が基礎となるフレームワークも更新することを知りました。
  • Aaron Stebnerの .NET Setup Verification Toolを実行しました。このツールは、.NET が正常にインストールされたことを示しました。(すべてのバージョンをチェックしたかどうかは忘れましたが、少なくとも 2.0 は機能していました)。
  • .NET 2.0 と .NET 3.5 を対象としたいくつかのミニ Hello World アプリケーションをテストしましたが、どちらも同じようにクラッシュしました。
  • windbg コマンドラインから .NET アプリを起動しようとしました。これを行うことで、単純な Hello World アプリケーションを呼び出すことができました。したがって、単純な .NET hello world は、windbg によって呼び出されるか、Visual Studio でデバッグを介して起動されると機能しますが、スタンドアロンで実行しようとすると機能しません。

WinDbg を使用してダンプ ファイルを作成しました。それは私にはそれほど明らかではありませんでした。 

FAULTING_IP:  mscorwks!PEImage::GetEntryPointToken+21 79f4ff9d f6401010        test    byte ptr [eax+10h],10h

EXCEPTION_RECORD:  0012f710 -- (.exr 0x12f710) ExceptionAddress: 79f4ff9d (mscorwks!PEImage::GetEntryPointToken+0x00000021) ExceptionCode: c0000005 (Access violation)   ExceptionFlags: 00000000 NumberParameters: 2    Parameter[0]: 00000000    Parameter[1]: 00000010 Attempt to read from address 00000010

FAULTING_THREAD:  00000b44
PROCESS_NAME:  MyProcess.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid    
DETOURED_IMAGE: 1    
NTGLOBALFLAG:  0    
APPLICATION_VERIFIER_FLAGS:  0    
MANAGED_STACK: !dumpstack -EE OS Thread Id: 0xb44 (0) Current frame:  ChildEBP RetAddr  Caller,Callee

EXCEPTION_OBJECT: !pe cb10b4 Exception object: 00cb10b4 Exception type: System.ExecutionEngineException Message: <none> InnerException: <none> StackTrace (generated): <none> StackTraceString: <none> HResult: 80131506    
MANAGED_OBJECT_NAME:  System.ExecutionEngineException    
CONTEXT:  0012f72c -- (.cxr 0x12f72c) eax=00000000 ebx=00000000 ecx=00000000 edx=0000000e esi=001a1490 edi=00000001 eip=79f4ff9d esp=0012f9f8 ebp=0012fa1c iopl=0         nv up ei pl zr na pe nc cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246 mscorwks!PEImage::GetEntryPointToken+0x21: 79f4ff9d f6401010        test    byte ptr [eax+10h],10h     ds:0023:00000010=?? Resetting default scope    
READ_ADDRESS:  00000010     
FOLLOWUP_IP:  mscorwks!PEImage::GetEntryPointToken+21 79f4ff9d f6401010        test    byte ptr [eax+10h],10h    
BUGCHECK_STR:  APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_SHUTDOWN    
PRIMARY_PROBLEM_CLASS:  NULL_CLASS_PTR_DEREFERENCE_SHUTDOWN
    DEFAULT_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE_SHUTDOWN    
LAST_CONTROL_TRANSFER:  from 79ef02b5 to 79f4ff9d    
STACK_TEXT:   79f4ff9d mscorwks!PEImage::GetEntryPointToken+0x21 79ef02b5 mscorwks!PEFile::GetEntryPointToken+0xa0 79eefeaf mscorwks!SystemDomain::ExecuteMainMethod+0xd4 79fb9793 mscorwks!ExecuteEXE+0x59 79fb96df mscorwks!_CorExeMain+0x15c 7900b1b3 mscoree!_CorExeMain+0x2c 7c817077 kernel32!BaseProcessStart+0x23    

SYMBOL_STACK_INDEX:  0    
SYMBOL_NAME:  mscorwks!PEImage::GetEntryPointToken+21    
FOLLOWUP_NAME:  MachineOwner    
MODULE_NAME: mscorwks    
IMAGE_NAME:  mscorwks.dll    
DEBUG_FLR_IMAGE_TIMESTAMP:  471ef729    
STACK_COMMAND:  .cxr 0012F72C ; kb ; dds 12f9f8 ; kb    
FAILURE_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE_SHUTDOWN_80000003_mscorwks.dll!PEImage::GetEntryPointToken    
BUCKET_ID:  APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_SHUTDOWN_DETOURED_mscorwks!PEImage::GetEntryPointToken+21    
WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/MyProcess_exe/2_4_4_39/4a8a192c/unknown/0_0_0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1

Followup: MachineOwner

編集 1:このエラーのイベント ログの詳細は、.NET ランタイム バージョン 2.0.50727.3053 - Fatal Execution Engine Error (7A097706)(80131506) であると述べています。

DotNetFatalExecutionErrorスクリーンショット
(ソース: blakerobertson.com )

編集 2 (10-7-09): この問題はまだアクティブです。

編集 3 (3-29-10): この更新は、私が問題を解決できなかったことを皆に知らせるためのものです。これをマシンとして使用していたお客様は、問題を解決することに興味を失い、マシンのイメージを再作成しました:(。しかし、すべての貢献に感謝します。

4

14 に答える 14

8

あなたのwindbg出力に基づいて、誰かがプロセスの起動時にプロセスにDLLを注入したように見えます.インジェクションは、ロードされたmscorwksのバージョン用に設計されていません. これがカジュアルなワークステーション (秘書など) である場合、MIS/IT がマルウェアを検査するために没収されます。サーバー ルームに置かれているマシンの場合、別のマシンへの再配置を顧客に依頼します。

これが他の顧客に起こるとは思いません.8年間の.NET開発で、あなたが説明している動作を（予想どおり）引き起こす可能性があるのは、古いバージョンのシステムで.NETアプリケーションを実行しようとすることだけです.インストールされているフレームワークのバージョン (たとえば、サポートがない場合、ほとんどのバージョンの Windows で標準のデバッグ/キャンセル ダイアログが表示される) であり、それはこの問題ではありません。これは、プロセッサ アーキテクチャ、フレームワーク バージョン、SP レベルとも関係がなく、市販の AV ソフトウェアや市販のネットワーク セキュリティ ソフトウェアとも関係ありません。

それは明らかにあなたのコードにあるものではなく、クライアントのために修正できるものではないと思います。お客様にターゲット マシンのイメージを再作成してもらう以外に、この問題を解決するために使用できるツールや一連の手順はありません。そうする前に、潜在的なマルウェア (具体的には、一般に配布されないマルウェア) について MIS/IT にゴースト化してもらいます。

関連資料: http://research.microsoft.com/apps/pubs/default.aspx?id=68568

幸運を。

于 2009-09-25T06:17:14.080 に答える
3

私たちのチームの数人のメンバーが最近同じ問題に直面し、Embassy Trust SuiteWave System でアンインストールした後、すべてが正常に戻ったことを発見しました。次のリンクが答えにつながりました。

http://social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/6e6b8496-c1f1-4fc9-bcc9-2129a6329804/

調査の一環として、彼らはこのSOの質問にも出くわし、他の人を助ける可能性のある解決策としてこれを投稿するように依頼しました.

于 2011-08-16T10:10:53.453 に答える
1

私は数ヶ月前に同様の問題を抱えていました（私はエラーコードを覚えていませんが）。多くのことを試した後、次のことが問題を解決しました（私が覚えている限り）：

.net一時フォルダー内のすべての一時ファイルを削除します（また、そのフォルダーのアクセス許可を確認します）

于 2009-09-24T02:51:07.657 に答える
1

大規模な展開でも非常によく似た問題が発生しました。すべてのケースで、フレームワークで修復を実行すると、試してみる問題が修正されました。

于 2009-09-22T23:17:27.200 に答える
1

私は最近同じ問題を抱えていて、これらの手順を実行しましたMicrosoft .NETアプリケーションがクラッシュし、.NETアプリが意図せずにクラッシュするのを修正しました

于 2010-11-19T14:44:10.133 に答える
1

同じ問題があり、発行ウィザードを使用して修正されました。これで、ターゲット マシンに Visual Basic Powerpack 3.0 パッケージがインストールされていないことがわかりました。それをインストールした後、それは魅力のように機能します。

于 2010-02-11T05:30:26.660 に答える
0

このリンクは、問題の解決に役立つ可能性があります。エラーの修正「.NETランタイムバージョン2.0.50727.3053 –致命的な実行エンジンエラー」[.NET]。

お客様のPCにインストールされているオペレーティングシステム（Windows XP、Vistaなど）は何ですか？

.NET Frameworkを（修復ではなく）完全にアンインストールしてから再インストールしようとしましたか？

于 2009-09-25T06:34:21.503 に答える
0

そこに「楽しい」ものを手に入れたようですね。私には手がかりはありませんが、とにかく暗闇の中で突き刺す私のカルマの提案があります。

1）Windowsによって割り当てられた通常のユーザー権限に加えて、.NETFramework専用のセキュリティ設定の個別のセットもあります。.NET SDKがインストールされている場合は、コントロールパネルで[Microsoft .NET Framework構成]ツールを探します（[管理ツール]の下にある場合があります）。設定のいずれかが開発マシンと異なるかどうかを確認してください。

2）あなたの顧客は職場のIT体制の管理下にあると思います。あなたまたはあなたの顧客がプログラムが機能する新しいWindowsインストールを手に入れることができるかどうかを確認してから、彼のITグループと協力して、プログラムが停止するまで一度に要件の1つ（セキュリティ設定、ウイルス対策プログラムなど）を適用します。働く。古き良き最後の動作状態のバグハント。もちろん、これは彼のIT部門からの協力を前提としているので、あなたのプログラムがどこかの幹部にとって重要であることを願っています。

于 2009-09-22T19:31:14.870 に答える
0

特効薬の修正はなく、許可の問題ではないと思います。

これが私が試すことです

  1. 64ビットマシンの場合は、32ビットモードに切り替えてみてください。32ビットdllが64ビットで実行されているのを確認しました。
  2. サーバー上に新しいWebサイトを作成し、その上でaspnet_regiisを実行します。
  3. 2.0および3.5フレームワークをアンインストールして再インストールします。完了したら、aspnet_regiisを確認して実行してください
于 2009-09-22T19:36:00.767 に答える
0

試してみるいくつかの提案：

  • vshost.exe の問題ではないことを確認するために、cdb/windbg で MyProcess.exe を実行して動作を確認します。
  • この問題は Read AV のように見えます。アプリがデバッガーで正常に動作する場合は、OS が .Net アセンブリの実行を mscorwks.dll にハンドオーバーする方法が破損している可能性があるため、.Net インストールの修復を試みます。
于 2009-09-22T19:43:27.997 に答える
0

すべてのクライアント マシンで発生するわけではないので、RAM でしょうか? 問題のあるマシンを再起動して、メモリ診断ツールを実行できますか?

過去のある時点で、このマシンの DEP がオンになっている可能性はありますか? この種のセキュリティでは .Net 例外は発生しません。アプリを実行できないため、エラーが発生する可能性はほとんどありません。

于 2009-09-24T21:59:46.123 に答える
0

WinDbg を使用して起動します。Son of Strike を使用すると、クラッシュの原因を正確に確認できるはずです。低レベルのアセンブリ ロード エラーが発生している可能性があります。過去にWinDbgを使用して同様の問題を解決しました。

于 2009-09-23T23:12:00.283 に答える
0

ユーザーがネットワーク共有からアプリケーションを起動していないことを確認してください。デフォルトでは、信頼できないソースからアプリケーションを起動しようとすると、.Net はセキュリティ例外をスローします。

この動作は、管理ツールの Microsoft .Net Framework 構成ユーティリティを使用して変更できます。

于 2009-09-23T23:16:21.360 に答える
0

私は最近、非常によく似た方法で現れる問題を抱えていました。特定のサードパーティの DLL が展開の一部ではないことが判明しました (bin ディレクトリからコピーしただけです)。すべての DLL を取得するセットアップ アプリケーションを作成し、それらが正しく展開されると、クラッシュしなくなりました。例外ではなくハードフェイルだったのが不思議です。

これは、すべての .NET アプリケーションに当てはまると言っているので、当てはまらないかもしれません。参照が残っている古いプロジェクト ファイルで作業している可能性がありますか?

于 2010-02-16T21:12:35.703 に答える