I'm trying to read the install path for an application, and I'm baffled at the behaviour I'm getting. First, here's the code that didn't work (formatted it a little so it doesn't take up a huge line):
LONG status = RegQueryValueEx(
hkRegistry,
"InstallPath",
0,
®Type, (LPBYTE)installPath,
®Size );
if (status == ERROR_SUCCESS) {
// Handle success.
}
I realized that it was failing on the call to RegQueryValueEx, so I decided to probe the return value by throwing it within an exception by adding:
else {
throw Exception( status );
}
But then... the code started to work and the call to RegQueryValueEx succeeded. I've been able to repeat this behaviour as long as I throw something within the else. If I comment out the body of the else, the error returns.
Edit: Okay, I tried calling MessageBox instead of an exception and I get the same behaviour. If I comment it out, it stops working again.
Is there a rational explanation for this?
It's possible that the buffer for installPath is too small compared to the value contained in regSize (which must be initialized to the size of the buffer).
If installPath is a stack-allocated value I suspect that it is overflown, causing the value of status to get overwritten.
Related
Good afternoon to all! I am writing a game engine using OpenGL + Win32 / GLFW. Therefore, I will say the project is large, but I have a problem that has led me to a dead end and I can't understand what the problem is. The problem is that I have a shared_ptr<Context> in the 'windows' class (it is platform-based) that is responsible for the context (GL, D3D). And everything works fine when I launch the application, everything is drawn normally, but when I start entering the cursor into the window, a crash occurs when any function calls from context, in my case is:
context->swapBuffers();
Here a crash:
std::shared_ptr<Context>::operator-><Context,0>(...)->**** was 0xFFFFFFFFFFFFFFE7.
Then I got into the callstack and saw that the context-> itself is non-zero, so the function should be called.
Then I searched for a long time for the problem and found that when I remove the Win32 message processing code, and when I remove it, errors do not occur when calling a function from context->. I removed everything unnecessary from the loop and left only the basic functions and tried to run it like this, because I thought that some other functions inside were causing this problem, but no.
while (PeekMessageW(&msg, NULL, NULL, NULL, PM_REMOVE) > 0) {
TranslateMessage(&msg);
DispatchMessageW(&msg);
}
That is, when I delete TranslateMessage() and DispatchMessage(), the error goes away. And then I finally got confused i.e I don't understand what is happening. And then I thought that maybe somehow the operating system itself affects that pointer, prohibits reading or something like that.
And then I paid attention to __vtptr in the call stack, and noticed that it is nullptr, and moreover it has the void** type. And also the strangest thing is that in the error I have ->**** was 0xffffffffffffffc7 as many as four consecutive pointers. What is it?
I understand I practically didn't throw off the code, because I have a big project and I think it doesn't make sense to throw everything, so I tried to explain the problem by roughly showing what is happening in my code. I will be grateful to everyone who will help :)
I am trying to make a socket on windows to connect to a server.
I am using the code from msdn's website, the winsock client code.
(Link: msdn.microsoft.com/en-us/library/windows/desktop/ms737591(v=vs.100).aspx )
In any case, when I try debugging said code I get the error message:
Unhandled exception at 0x58a714cf (msvcr100d.dll) in Application.exe: 0xC0000005: Access violation reading location 0x00000032.
It asks me if I want to break or continue, if I continue the same error message simply keeps popping up. If I press break it takes me to line 1643 in the file output.c .
Simply put, I have no idea about what to do to make it work, and I'd appreciate any help given.
EDIT:
A reply to all comments given thus far:
The surrounding relevant code in output.c is:
if (flags & (FL_LONG|FL_WIDECHAR)) {
if (text.wz == NULL) /* NULL passed, use special string */
text.wz = __wnullstring;
bufferiswide = 1;
pwch = text.wz;
while ( i-- && *pwch )
++pwch;
textlen = (int)(pwch - text.wz);
/* textlen now contains length in wide chars */
} else {
if (text.sz == NULL) /* NULL passed, use special string */
text.sz = __nullstring;
p = text.sz;
while (i-- && *p) //THIS IS WHERE IT BREAKS
++p;
textlen = (int)(p - text.sz); /* length of the string */
}
This is not code that I have written but innate code that already exists.
EDIT NR 2:
This is a printscreen displaying my call stack.
I do not have 10 reputation so I cannot show the image, so here is a link to the image:
http://tinypic.com/r/5n6ww9/5
On it you can see my call stack
The file output.c has the code that handles the printf family of functions.
The fact that you have an error here is probably due to a malformed printf function call in your code. Maybe you have specified an invalid print format or have not provided enough arguments.
When your program crashes, click Break and look at the call stack in the debugging windows to see where - in your code - the function is called, and with what arguments.
I suspect you are trying to print a NULL string or something. When you have found the printf call (if that's what it is), edit your question to show that section of source code and/or use the debugger to examine the variables used a arguments to the function and make sure they are all correct.
Without seeing the code that you've written, at the location of the crash, it's not possible to give a more precise answer.
Or you may insert a null string to CString.format like below:
CString str;
str.format("%s"); //A null string
where it should be
str.format("%s",mes);
where mes is char mes[20] for example
or any other variable
So the point is there may be some mistake in CString.format or Printf
Good Luck.
So far my program is working pretty well. Unfortunately when I press ctrl + alt + del it throws an error. Now I have read this question:
E_ACCESSDENED when using ctrl alt del
In which it is mentioned that the computer switches to a different screen (in which you don't have any writing permissions). It's just that I have no idea how to trace if I have writing permission in the current screen.
My code looks like:
void D3D::StartFrame() {
HRESULT result;
result = pDevice->Clear( 0,NULL,D3DCLEAR_TARGET,D3DCOLOR_XRGB(FRAME_BG_R,FRAME_BG_G,FRAME_BG_B),0.0f,0 );
assert( !FAILED( result ) );
result = pBackBuffer->LockRect( &backRect,NULL,NULL );
assert( !FAILED( result ) );
}
void D3D::EndFrame() {
HRESULT result;
result = pBackBuffer->UnlockRect();
assert( !FAILED( result ) );
result = pDevice->Present( NULL,NULL,NULL,NULL );
assert( !FAILED( result ) );
}
Currently I am running the "StartFrame()" function each frame followed by some actions that should be done during the frame. At the end it will call the "EndFrame()" function that will unlock the drawing rectangle.
Now the error that occurs comes from the last assert (the StartFrame() assert doesn't fail?). Should I change these functions to return booleans telling the program if it should continue or not? Should I make it stop the entire program (which feels a bit odd)? Perhaps I am handling the rectangle locking the wrong way (should it work with asserts)?
Error: Assertion failed! - !FAILED(result)
Any help/advice would be appriciated !
First of all, whenever you get an error, before doing somethig, and before even thinking about what happened, you must check what exactly error message said.
In case of DirectX 9, you must not only check if HRESULT variable FAILED but get detailed info from it. You can get details from it using DXGetErrorString() and/or DXGetErrorDescription() functions (dxerr.h + dxerr.lib). For example, you can handle you errors by writing a small helper function, that accepts HRESULT and shows MessageBox() with details if it FAILED. Also, there is a good DXTrace() macro as a quick solution. Or, as a quickest lazy solution, you can just set a breakpoint right after function fail, and inspect value of HRESULT variable in debug watcher.
In your case, because we don't have error description in your post, we can only guess what happened (that's what guys from SO doesn't like the most). And I suspect here Device Lost state. That state sometimes happens when your app looses focus (Alt+tab, Ctrl+Alt+Del, etc.). To prevent crashes you must handle such exceptional states as described on MSDN or this short tutorial.
Of course, my guess can be wrong here, because I dont't know, what exactly happened. Please add proper error handling and provide additional information to get concrete help.
Happy coding!
I am working with HANDLES, the first one, nextColorFrameEvent is an event handler and the second one is a stream handler. They are being initialized in the following piece of code:
nextColorFrameEvent = CreateEvent( NULL, TRUE, FALSE, NULL );
hr = nui->NuiImageStreamOpen(
NUI_IMAGE_TYPE_COLOR,
NUI_IMAGE_RESOLUTION_640x480,
0,
2,
nextColorFrameEvent,
&videoStreamHandle);
I want to properly deal with them on destruction, while not creating errors at the same time. Sometimes the initializer wont be called, so both HANDLEs are still NULL when the software comes to an end. Thats why I want to check first if the HANDLEs are properly initialized etc. and if they are, I want to close them. I got my hands on the following piece of code for this:
if (nextColorFrameEvent && nextColorFrameEvent != INVALID_HANDLE_VALUE)CloseHandle(nextColorFrameEvent);
#ifdef QT_DEBUG
DWORD error = GetLastError();
qDebug()<< error;
#endif
if (videoStreamHandle && videoStreamHandle != INVALID_HANDLE_VALUE)CloseHandle(videoStreamHandle);
#ifdef QT_DEBUG
error = GetLastError();
qDebug()<< error;
#endif
But this is apperently incorrect: if I do not run the initializer and then close the software this piece of code runs and gives me a 6:
Starting C:\...\Qt\build-simpleKinectController-Desktop_Qt_5_0_2_MSVC2012_64bit-Debug\debug\simpleKinectController...
6
6
C:\...\Qt\build-simpleKinectController-Desktop_Qt_5_0_2_MSVC2012_64bit-Debug\debug\simpleKinectController exited with code 0
which means:
ERROR_INVALID_HANDLE 6 (0x6) The handle is invalid.
Which means that closeHandle ran anyway despite the tests. What tests should I do to prevent closing when the handle is not a valid HANDLE?
Bonus question: if I run the initializer this error will no longer appear when only closing colorFrameEvent, but will still appear when closing videoStreamHandle:
Starting C:\...\Qt\build-simpleKinectController-Desktop_Qt_5_0_2_MSVC2012_64bit-Debug\debug\simpleKinectController...
0
6
C:\...\Qt\build-simpleKinectController-Desktop_Qt_5_0_2_MSVC2012_64bit-Debug\debug\simpleKinectController exited with code 0
Do I need a diffent function to close a stream handler?
nui->NuiImageStreamOpen(...) does not create a valid Windows handle for the stream but instead it creates an internal handle inside the driver side.
So you can not use windows API to release/close stream handle !!!
To do that just call nui->NuiShutdown(). I have not yet used the callback event but I think its a valid windows handle and should be closed normally.
if you need just to change settings you can always call nui->NuiImageStreamOpen(...) with new settings. No need to shutdown ...
I would also welcome function nui->NuiImageStreamClose(...); because current state of API complicates things for long term running aps with changing sensor configurations.
CreateEvent (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682396(v=vs.85).aspx) returns NULL if an event was not created.
You are checking against INVALID_HANDLE_VALID which is not NULL.
You are probably trying to double-close a handle. That is likely to generate ERROR_INVALID_HANDLE 6. You can't detect this with your test, because the first CloseHandle(nextColorFrameEvent); did not change nextColorFrameEvent.
The solution is to use C++ techniques, in particular RAII. There are plenty of examples around how to use shared_ptr with HANDLE. shared_ptr is the standard solution to run cleanup code at most once, after everyone is done, and only if anybody actually allocated a resource.
there is a good way of debugging that I'm particularly fond of, despite being all writen in macros, which are nasty, but in this case they work wonders.
Zed's Awesome Debug Macros
there are a couple of things I like to change though. They make extensive use of goto, which I tend to avoid, specially in c++ projects, because otherwise you wouldn't be able to declare variables mid-code. This is why I use exit(-1) instead, or, in some projects, I mod the code to try, throw, catch c++. Since you are working with Handles, a good thing would be setting a variable and telling the program to close itself.
here is what I mean. Take this piece of code from the macros (i assume you would read the exercise and familiarize with the macros):
#define check(A, M, ...) if(!(A)) { log_err(M, ##__VA_ARGS__); errno=0; goto error; }
i'd change
goto error;
to something like
error = true;
the syntax inside the program would be something like, and I took it from a multithread program I'm writing myself:
pRSemaphore = CreateSemaphore(NULL, 0, MAX_TAM_ARQ, (LPCWSTR) "p_read_semaphore");
check(pRSemaphore, "Impossible to create semaphore: %d\n", GetLastError());
As you can see, GetLastError is only called when pRSemaphore is set to null. There are somewhat fancy mechanisms behind the macro (at least they are fancy for me), but they are hidden inside the "check" mask, so you needn't worry about them.
next step is to treat the error with something like:
inline void ExitWithError(bool &err) {
//close all handles
//tell other related process to do the same if necessary
exit(-1);
}
or you could just call it inside the macro like
#define check(A, M, ...) if(!(A)) { log_err(M, ##__VA_ARGS__); errno=0; ExitWithError(); }
hope I could be of any help
I am trying to load an image using SHLoadImageFile,but its returning invalid handle.
I am puzzled where the fault is.Because the path given to SHLoadImageFile is absolutely fine.
The question title currently is "SHLoadImage is returning error code 6". But SHLoadImage return is a handle, not an error code. So perhaps this means that you have called GetLastError?
If so, then error code 6 is defined in <winerror.h> as
//
// MessageId: ERROR_INVALID_HANDLE
//
// MessageText:
//
// The handle is invalid.
//
#define ERROR_INVALID_HANDLE 6L
The documentation does not however say anything about SHLoadImage setting the last error code, so perhaps this is something from earlier in the execution. Try using SetLastError to set the last error code to 0 before calling SHLoadImage.
For more specific advice you need to include more specific information, like showing the code with the "absolutely fine" path. If it really is, perhaps the file doesn't exist. Or is not a valid image.
Cheers & hth.,