私には奇妙な状況があります。私のゲームは間違いなくデバッグ情報を使用してビルドされており、ブレークポイントにヒットしてコードをステップ実行し、データを確認することができます。異常な設定はありません。マルチスレッドを問題として除外しました。実際のバグと正当なクラッシュがある場合、コール スタックは得られません。典型的なクラッシュバグは
First-chance exception at 0x004678da in Democracy3Debug.exe: 0xC0000005: Access violation reading location 0x0000004c.
Unhandled exception at 0x774015de in Democracy3Debug.exe: 0xC0000005: Access violation reading location 0x0000004c.
そして、コールスタックは ntdll といくつかの逆アセンブリです。どこかでオプションを変更したに違いありませんが、何を想像することはできません。何か案は？
これらのエラーは、プロセスが読み書きできないメモリにアクセスしようとしたことによるハードウェア例外を示しています。具体的には、何らかのポインタが参照するアドレスから 76 バイト離れた要素に直接的または間接的にアクセスしようとしているように見えますが、そのポインタは実際には null です (したがって、アクセス違反の読み取り位置 0x0000004c)。
デバッグ情報は決して無効ではない可能性があります。たとえば、許可しない Windows API 関数に null ポインターを渡した場合など、正当に nt.dll 内のコードに含まれている可能性があります。nt.dll 用のシンボルが読み込まれていない場合、有用なコール スタックは得られません。
また、Windows API によって何らかのコールバックが呼び出されるまで使用されなかった、渡された不良ポインターがアクセス違反の原因である可能性もあります。これは、コードがスタック フレームのどこにも表示されない理由を説明している可能性があります。
VS IDE でブレーク オン スローを有効にすると ([デバッグ] -> [例外] で、関連する例外の種類のボックスをオンにします)、これが発生したときに早期にブレークするのに役立ちますが、合法的にコードから直接ではない場合、問題の診断には役立たない可能性があります。
構造化された例外処理を使用して、これらの例外と C++ の例外をキャッチ目的で統合することもできます。また、シンボル サーバーを使用して Windows DLL のシンボルを取得することも検討してください。
あなたの例外はキャッチされていないので、コールスタックをメインに移動してアプリを終了しています。
MSDN:
現在の例外に一致するハンドラー (または省略記号のキャッチ ハンドラー) が見つからない場合は、定義済みの終了ランタイム関数が呼び出されます。
通常、例外がスローされたときにデバッグを一時停止できるオプションがあります。
方法: 例外がスローされたときに中断する (Visual Studio 2012)
また、最上位に catch ステートメントを配置し、キャッチ時に例外を調べることもできます (.what() は多くの場合、説明を提供します)。
更新: この例外はアクセス違反であるため、おそらくキャッチできません (C++ 例外ではありませんが、一時停止はまだ動作するはずです)。Windows を使用している場合は、SEH を使用してキャッチできます。