I'm writing a simple renderer using the d3d11 library in Visual Studio 2019 and it builds and runs fine. However when I try running the Graphics Debugger it immediately throws a read access violation for address 0x0000000000000000 ( which is clearly incorrect ).
The exception is thrown from the DXCaptureReplay dll on the line
DeviceContext.PSSetShader(InShaderToBind.Shader.PS, NULL, 1);
Where InShaderToBind.Shader.PS is a pointer to ID3D11PixelShader
It got the most weird when I out of a lack of ideas tried
int X = 0;
ID3D11ClassInstance* FakedClassInstance = reinterpret_cast<ID3D11ClassInstance*>(&X);
DeviceContext.PSSetShader(InShaderToBind.Shader.PS, &FakedClassInstance, 1);
As this will make the exception not throw until I try to capture a frame ( Which I guess makes sense as that pointer will only be valid for the scope where X is still valid )
The MSDN documentation states that NULL should be a perfectly valid argument to pass to PSSetShader ( as noted here: https://learn.microsoft.com/en-us/windows/win32/api/d3d11/nf-d3d11-id3d11devicecontext-pssetshader )
Any ideas for what might be going wrong?
( If I comment out PSSetShader the exception is not thrown and I can take captures )
If you enable the Direct3D Debug Device, you would see in your debug output window:
D3D11 CORRUPTION: ID3D11DeviceContext::PSSetShader: Second parameter (ppClassInstances) corrupt or unexpectedly NULL. [ MISCELLANEOUS CORRUPTION #14: CORRUPTED_PARAMETER2]
NULL (or better yet nullptr) is fine for ppClassInstances only if NumClassInstances is 0. Try:
DeviceContext.PSSetShader(InShaderToBind.Shader.PS, NULL, 0);
Generally you should make sure your program runs without emitting ERROR or CORRUPTION messages from the debug layer before attempting to use PIX or the VSGS tool.
See Microsoft Docs and this blog post.
Related
I have a problem I just can't find information for. The following code is causing the issue (I have left out a lot of code for brevity, but as I will explain, this code seems to work fine):
mHDC = GetDC(mHWnd);
int format = ChoosePixelFormat(mHDC, &pixelFormat);
SetPixelFormat(mHDC, format, &pixelFormat);
mHGLRC = wglCreateContext(mHDC);
wglMakeCurrent(mHDC, mHGLRC);
mHWnd is obtained through 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() is causing an invalid handle first-chance exception in the debugger when I am using the Application Verifier with only Handles and Cuzz enabled. These two together cause the exception to trigger. Without both of these enabled (even if I just do one or the other), the exception isn't thrown and everything works okay. When I run the application without attaching to the debugger, the application crashes instead.
Even though the exception is raised, once I hit wglMakeCurrent() (by continuing debugging after and ignoring the exception), all the variables seem to end up with valid values anyway:
mHWnd == 0x1a1064e
mHDC == 0x440119c0
format == 7
mHGLRC == 0x10000
The stack trace looks like this:
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()
And the active thread is a vfcuzz.dll thread, which is obviously allowing Cuzz to do it's business. vfbasics.dll in the stack trace is where the handle checker is, and as I said, only the handle checker is enabled.
For completion sake, here is the actual exception message:
First-chance exception at 0x00000000772012F7 (ntdll.dll) in Tests.exe: 0xC0000008: An invalid handle was specified.
I am assuming it isn't a bug in the Application Verifier that is causing it to throw an exception that shouldn't exist and crashing the program. I am just confused as to why it is throwing the exception when clearly I am getting valid values back from the function calls. I don't really want to ignore it until I understand what is going on.
It doesn't look like a problem with your code. The only handle ChoosePixelFormat takes is an HDC and the one you're giving it is presumably valid (although in the code you're showing there's no checking that GetDC succeeded, I assume you just left that out for brevity).
A first-chance exception isn't necessarily a problem. It simply means an exception occurred, and this is the first chance to handle it. My guess is the exception is most likely happening within the ChoosePixelFormat function itself (or within a function that ChoosePixelFormat calls) and being handled there - it's only because you are debugging that you actually find out about it. In every day usage the exception would be handled quietly and you'd never even know it had happened.
I have following message while I am in debug mode in Visual studio 2010 Unhandled exception at 0x76c5f9e2 in test.exe: 0xC0000008: An invalid handle was specified.When I run this in regular mode I don't get this error.
The debugger stops in close.c at this line
CloseHandle( (HANDLE)_get_osfhandle(fh) ) )
Does anyone have any sugestion how such error could be avoided?
Don't handle this exception, but avoid the situation were you pass an invalid handle!
Edit:
In debug mode, the code gives you a hint that something is wrong. So you should fix that error instead of handle the exception afterwords!
I just had the same problem.
I checked for stack corruption, corruption of the handle etc. Eventually I discovered that I shouldn't have been calling CloseHandle()!
This was a handle returned by FindFirstFile(), the correct disposal function is FindClose(), not CloseHandle().
I have a Visual C++ 9 Win32 application that uses a third-party library. When a function from that library is called with a certain set of parameters the program crashes with "exception code 0xC000000D".
I tried to attach Visual Studio debugger - no exceptions are thrown (neither C++ nor structured like access violations) and terminate() is not called either. Still the program just ends silently.
How does it happen that the program just ends abnormally but without stopping in the debugger? How can I localize the problem?
That's STATUS_INVALID_PARAMETER, use WinDbg to track down who threw it (i.e. attach WinDbg, sxe eh then g.
Other answers and comments to the question helped a lot. Here's what I did.
I notices that if I run the program under Visual Studio debugger it just ends silently, but if I run it without debugger it crashes with a message box (usual Windows message box saying that I lost my unsaved data and everyone is sooo sorry).
So I started the program wihtout debugger, let it crash and then - while the message box was still there - attached the debugger and hit "Break". Here's the call stack:
ntdll.dll!_KiFastSystemCallRet#0()
ntdll.dll!_ZwWaitForMultipleObjects#20() + 0xc bytes
kernel32.dll!_WaitForMultipleObjectsEx#20() - 0x48 bytes
kernel32.dll!_WaitForMultipleObjects#16() + 0x18 bytes
faultrep.dll!StartDWException() + 0x5df bytes
faultrep.dll!ReportFault() + 0x533 bytes
kernel32.dll!_UnhandledExceptionFilter#4() + 0x55c bytes
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//OurCodeInvokingThirdPartyLibraryCode
so obviously that's some problem inside the trird-party library. According to MSDN, UnhandledExceptionFilter() is called in fatal situations and clearly the call is done because of some problem in the library code. So we'll try to work the problem out with the library vendor first.
If you don't have source and debugging information for your 3rd party library, you will not be able to step into it with the debugger. As I see it, your choices are;
Put together a simple test case illustrating the crash and send it onto the library developer
Wrap that library function in your own code that checks for illegal parameters and throw an exception / return an error code when they are passed by your own application
Rewrite the parts of the library that do not work or use an alternative
Very difficult to fix code that is provided as object only
Edit You might also be able to exit more gracefully using __try __finally around your main message loop, something like
int CMyApp::Run()
{
__try
{
int i = CWinApp::Run();
m_Exitok = MAGIC_EXIT_NO;
return i;
}
__finally
{
if (m_Exitok != MAGIC_EXIT_NO)
FaultHandler();
}
}
I'm currently doing some tests using Cairo to replace some existing GDI/GDI+
code in Visual C++ 2010 and it seems to be working fine, but I'm getting
an error message each time I close down my application :
"First-chance exception at 0x68e629dc in CairoTest.exe: 0xC0000005:
Access violation reading location 0xabababa7"
This error only happens if I've called cairo_paint(cr) while the
application is running - if I comment this line out, it disappears. The
only Cairo code in my application so far is :
CChildView::CChildView()
{
testsurface = cairo_image_surface_create_from_png("BlackShinyBackground.png");
}
CChildView::~CChildView()
{
cairo_surface_destroy(testsurface);
}
void CChildView::OnPaint()
{
CPaintDC dc(this);
cairo_surface_t *surface = cairo_win32_surface_create(dc.m_hDC);
cairo_t *cr = cairo_create (surface);
cairo_set_source_surface(cr, testsurface, 0, 0);
cairo_paint(cr);
cairo_destroy (cr);
cairo_surface_destroy (surface);
}
Can anybody point me in the direction of what I'm doing wrong?
Like I said, the code appearsto be working fine, but I don't like just ploughing on regardless when I can see errors.
A first chance exception doesn't necessarily mean much -- they're a routine part of Windows' memory management. Basically, any time you access something that's in virtual memory (e.g., on the paging file) a first chance exception is created. The OS handles it by paging in the required data into physical memory, then your code can continue executing.
If/when you see a second-chance exception, it means the OS didn't handle the exception, so unless you have a handler for it in your code, chances are pretty good that is signals a real problem.
I am using OpenCV 1 to do some image processing, and am confused about the cvSetErrMode function (which is part of CxCore).
OpenCV has three error modes.
Leaf: The program is terminated after the error handler is called.
Parent: The program is not terminated, but the error handler is called.
Silent: Similar to Parent mode, but no error handler is called
At the start of my code, I call cvSetErrMode(CV_ErrModeParent) to switch from the default 'leaf' mode to 'parent' mode so my application is not terminated with an exception/assertion pop up.
Unfortunately 'parent' mode doesn't seem to be working. I still get the message dialog pop up, and my application still terminates.
If I call cvSetErrMode(CV_ErrModeSilent) then it actually goes silent, and no longer quits the application or throws up a dialog... but this also means that I dont know that an error has occurred. In this case, I think the mode is being set correctly.
Has anyone else seem this behaviour before and might be able to recommend a solution?
References:
cvSetErrMode function reference
Open CV Error handling mode reference
I am going to answer my own question, because after some fiddling around I have worked out what happens.
When you switch to 'parent' mode instead of leaf mode, there is an error handler that gets called cvGuiBoxReport(). cvGuiBoxReport() is the default error handler. It seems that even in parent mode, cvGuiBoxReport() still terminates your application! Oops.
So, to get around that you can write your own error handler, and redirect the error to be handled and NOT terminate the application.
An example error handler:
int MyErrorHandler(int status, const char* func_name, const char* err_msg, const char* file_name, int line, void*)
{
std::cerr << "Woohoo, my own custom error handler" << std::endl;
return 0;
}
You can set up parent mode and redirect your error with:
cvSetErrMode(CV_ErrModeParent);
cvRedirectError(MyErrorHandler);
In a week of servers crashing from uploading corrupt or empty images to our image processing server, here are some thoughts on how I solved the intricacies of OpenCV's error handling. We are using V2.2 in a C++ server.
The problem arises in cv::imread() and cv::imdecode() when the image to be loaded is corrupt (or empty). Normally OpenCV just exits the process with with some error messages, not a good idea when you're running a server which should work all the time.
Reviewing the source code at https://code.ros.org/trac/opencv/browser/trunk/opencv/modules/core/include/opencv2/core/core.hpp I ignored the hint in the source comments for cv::setBreakOnError() and discovered the that following pattern works:
cv::setBreakOnError(true); // Can be set globally
...
...
cv::Mat srcImage = cv::imread(filename, 1);
if (!srcImage.data) throw std::exception("bad image");
cv::imread() will now not exit the process, but passes control to your own exception handling, so you can do with it what you like.
Finding this has saved a lot of heartbreak.