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().
Related
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.
In my real time image tracking solution, whenever i am calling detectAndCompute i get an exception thrown.
The exception doesnt crash the program, and the tracking still works (on my machine) but due to the fact that it is constantly throwing the exception, I am seeing some major performance setbacks. Here is the exception:
Exception thrown at 0x00007FFF0FBEA839 in OpenCV2.exe: Microsoft C++ exception: ipp::IwException at memory location 0x0000004CB72FC5C8.
I tried printing the exception to get details with a try-catch clause but it didnt give me any info. Here is the line that throws this exception:
algo->detectAndCompute(frame, mask, keypoints2, descriptors2, false);
This is harmless, see for example https://github.com/opencv/opencv/issues/9718.
If you run your code outside of the debugger you will not see the exception printout.
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'm currently suffering from some strange exceptions that are most probably due to me doing something incorrectly while interacting with opencv:
First-chance exception at 0x7580b9bc in xxx.exe: Microsoft C++ exception: cv::Exception at memory location 0x00c1c624..
I've already enabled the Thrown field in the Debug -> Exceptions menu, however I really can't figure out where in my code the exception is thrown.
How can I debug this?
EDIT
the stack frame reads like this (my app won't even show up in the list!):
KernelBase.dll!7580b8bc()
[Frames below may be incorrect or missing ]
KernelBase.dll!7580b8bc()
opencv_core242d.dll!54eb60cc()
You could wrap your entire main in a try catch block which prints out the exception details. If the open CV API can throw exceptions, you will need to think about handling them anyway as part of your design:
try
{
// ... Contents of your main
}
catch ( cv::Exception & e )
{
cerr << e.msg << endl; // output exception message
}
OpenCV has this handy function called cv::setBreakOnError
If you put the following into your main before any opencv calls:
cv::setBreakOnError(true);
then your program will crash, because OpenCV will do an invalid operation (dereferencing a null pointer) just before it would throw cv::Exception normally. If you run your code in a debugger, it will stop at this illegal operation, and you can see the whole call stack with all of your codes and variables at the time of the error.
I´ve got this problem by using OpenCV with WebCam. The problem in my case is that the program is trying to read an image when the Cam hasn't been initialized.
my error code:
// open camera
capture.open(0);
while (1){
//store image to matrix // here is the bug
capture.read(cameraFeed);
The solution
// open camera
capture.open(0);
while (1){
//this line makes the program wait for an image
while (!capture.read(cameraFeed));
//store image to matrix
capture.read(cameraFeed);
(sorry about my english)
Thanks
My VC++ code was working (executing) perfectly alright & now all of a sudden I don't understand why am I getting the error "Debug assertion failed".
file:f\dd\vctools\crt_bld\self_x86\crt\src\fclose.c.
I am using VS2008 on WIn7 64bit OS.
What might be the reason that a code which was working fine started breaking in this manner all of a sudden without any code changes?
Can anyone kindly help me in getting rid of this error?
I saw in the call stack that the code before this is in the file
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\crt\src\crt0dat.c
while ( pfbegin < pfend )
{
/*
* if current table entry is non-NULL, call thru it.
*/
if ( *pfbegin != NULL )
(**pfbegin)();
++pfbegin;
}
And yes, fclose() is receiving a null file pointer. I seriously don't understand why is this getting wrong file pointer value, all of a sudden without me doing any change to the code or to the environment.
Could you provide the code which calls fclose()?
I may guess that fopen() failed to open the file returning NULL, e.g. because file doesn't exist. You didn't check for this error and passed NULL handle to fclose().