3

情報が見つからないという問題があります。次のコードが問題を引き起こしています (簡潔にするために多くのコードを省略しましたが、後で説明するように、このコードは問題なく動作するようです)。

mHDC = GetDC(mHWnd);
int format = ChoosePixelFormat(mHDC, &pixelFormat);
SetPixelFormat(mHDC, format, &pixelFormat);
mHGLRC = wglCreateContext(mHDC);
wglMakeCurrent(mHDC, mHGLRC);

mHWndを通じて得られるCreateWindow()

const HINSTANCE hInstance(static_cast<HINSTANCE>(::GetModuleHandle(NULL)));

mHWnd = CreateWindow(wndClass.lpszClassName, L"Test Application", style, CW_USEDEFAULT, CW_USEDEFAULT, clientRect.right, clientRect.bottom, NULL, NULL, hInstance, NULL);

ChoosePixelFormat()ハンドルと Cuzz のみを有効にして Application Verifier を使用しているときに、デバッガーで無効なハンドルの初回例外が発生します。これら 2 つが一緒になると、例外がトリガーされます。これらの両方を有効にしないと (どちらか一方だけを実行しても)、例外はスローされず、すべて正常に動作します。デバッガーにアタッチせずにアプリケーションを実行すると、代わりにアプリケーションがクラッシュします。

例外が発生したとしても、一度ヒットwglMakeCurrent()すると(デバッグを続行して例外を無視することにより)、とにかくすべての変数が有効な値になるようです:

mHWnd == 0x1a1064e
mHDC == 0x440119c0
format == 7
mHGLRC == 0x10000

スタック トレースは次のようになります。

ntdll.dll!00000000772012f7()
vfbasics.dll!000007feedaa81b4()
KernelBase.dll!000007fefd1610dc()
vfbasics.dll!000007feedaa7ce9()
vfcuzz.dll!000007fee5075179()
nvoglv64.dll!000000006979b732()
vfbasics.dll!000007feedaac1d5()
kernel32.dll!0000000076fa652d()
ntdll.dll!00000000771dc521()

そして、アクティブなスレッドはvfcuzz.dllスレッドであり、明らかに Cuzz が仕事をすることを可能にしています。vfbasics.dllスタック トレースの はハンドル チェッカーの場所であり、前述のとおり、ハンドル チェッカーのみが有効になっています。

最後に、実際の例外メッセージを次に示します。

First-chance exception at 0x00000000772012F7 (ntdll.dll) in Tests.exe: 0xC0000008: An invalid handle was specified.

存在しないはずの例外をスローしてプログラムをクラッシュさせているのは、Application Verifier のバグではないと思います。関数呼び出しから有効な値が明らかに返されているのに、なぜ例外がスローされるのか、私は混乱しています。何が起こっているのかを理解するまで、それを無視したくありません。

4

1 に答える 1