I have an application that is built against OpenSceneGraph (2.6.1) and therefore indirectly OpenGL. The application initializes and begins to run, but then I get the following exception "attempt was made to execute an invalid lock sequence" in OpenGL32.dll. When I re-run it, I sometimes get this exception, and sometimes an exception about a "privileged instruction". The call stack looks like it is corrupted, so I can't really tell exactly where the exception is being thrown from. I ran the app quite a bit a couple of days ago and never saw this behavior. Since then I have added an else clause to a couple of ifs, and that is all. My app is a console application, is built with Visual Studio 2008, and it sets OpenScenGraph to SingleThreaded mode. Anybody seen this before? Any debugging tips?
Can you reproduce it with one of the standard examples?
Can you create a minimal app that causes this?
Do you have a machine with a different brand video card you can test it on (eg Nvidia vs. ATI) there are some issues with openscenegraph and bad OpenGL drivers.
Have you tried posting to osg-users#lists.openscenegraph.org
The problem turned out to be our app was picking up an incorrect version of the OpenGL DLL , instead of the one installed in System32.
Related
Starting roughly two days ago, every D3D11 application I've run has exploded within the first 30 seconds of being started [including code I've never touched].
I'm using Visual Studios 2013 with the Windows 8.1 SDK installed [reinstalled today for good measure].
Since it's a D3D error, it only explodes in Debug, but a crash somewhere is a problem somewhere else.
D3D11 CORRUPTION: ID3D11DeviceContext::RSGetScissorRects: First parameter out of range. [ MISCELLANEOUS CORRUPTION #13: CORRUPTED_PARAMETER1]
I've never used ID3D11DeviceContext::RSGetScissorRects for any purpose ever. I don't even know what parameters it takes in, spits out, what it does or any combination of otherwise.
Since there's a ID3D11DeviceContext::RSGetScissorRects I assume there's a ID3D11DeviceContext::RSSetScissorRects as well, but as with ID3D11DeviceContext::RSGetScissorRects, I don't know what it does.
Since it's relatively important for me to be able to Graphics, what's the potential solution for this problem?
This is my current DirectX11 initialization as it stands.
Members of my team are able to run our DirectX11 Application for hours without problems, but when it's passed to my machine via USB...explosions
Any help would be greatly appreciated.
As per comments, in your call stack "ltc_game32" appears to be attributable to Raptr, which is part of AMD Gaming Evolved. This has hooked your D3D11 application to provide some sort additional capture/record functionality and appears not to run "clean" with regards to the D3D11 Debug Layer.
Try uninstalling Raptr from the Control Panel to remove this additional "feature" of the driver and see if the problem continues to occur. It may also be sufficient to simply close AMD Gaming Evolved from your task tray and see if the problem goes away.
My team is developing an application that is capable of recording videos and exporting the video into .wmv format file.
The export function is done via a method that utilizes windows API method derived from WMVCore.dll library.
However, on some PCs, this export function gets into crashes and according to the dump file taken from the crash, it appears that the last method called was WMVCore.WMIsContentProtected method. The call stack from the dump file is like below:
379fe8d8 65aa0cdb 299f94f0 00025800 379fe8f4
WMVCORE!WMIsContentProtected+0x4bc3 379fe970 6102e07e 1cae3f20
299f94f0 379fece8 WMVCORE!WMCreateWriterPushSink+0x1e278
It is really frustrating getting this crash without any more information out of the dump file. I also thought that the library might be corrupted on that specific PC, but there is no way to re-install the library as it comes with Windows Media Player. Any suggestion would be appreciated.
The code simply called WMVCore.WMCreateWriterPushSink which is followed by WMVCore.WMIsContentProtected. The OS version is Windows 7 Enterprise 64 bit. The application is a web based application on IE, in which case when the crash happens, IE would also crash and stop. The version of the WMVCore.dll is 12.0.7601.17514 and the question here is whether anyone has experienced the same issue and if yes, what sort of things can be tried/done to prevent this crash from happening?
I am developing a Fifteen Puzzle Game in QT C++. Game works sometimes fine and sometimes crashed during run. I don't know the problem. I looked into different forums and found different suggestions. Some say this error is due to missing dll etc.
A window appears with Error is below
Microsoft Visual C++ Runtime Library
This application has requested the runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
I solved the problem: Actually I was accessing a vector location which was not available. assert() helped me to troubleshoot. Thanks #DNT
First things first: Platform is Windows 7 64-bit, language is VC++, IDE is VS2010. Graphics card is nVidia GTX 460, drivers are version 290.53.
So here's the situation. I am currently working in OpenGL using Glew 1.7 and Glut. I set everything up a few days ago and managed to successfully code and complete an assignment for my classes. The assignment ran beautifully and displayed and did everything it was supposed to. That was wonderful. So I submitted my assignment and didn't touch it again until tonight.
Now, tonight I tried running the code again and instead of my beautifully tessellated polygons I am getting a plain white window. As far as I know, nothing related to OpenGL has changed on my system since I last ran the code. I haven't changed the code at all, I haven't changed the graphics drivers, I haven't changed anything that I am aware of. I couldn't seem to find anything related to this kind of problem, and I am at a loss of what could possibly be causing the issue. I even tried recompiling Glew, but it didn't change anything. I know it's not a code issue since it was working fine a few days ago and nothing has changed, so it has to be a configuration issue.
Could someone please point me in the right direction?
Edit
One more thing to add to this. When I was originally doing the project in question, attempting to run it produced the error message "unable to find glew32d.dll" until I placed glew32d.dll and glut32.dll in the source folder of my project.
Now, I don't remember deleting them from my project folder, but when I tried to debug it last night, I noticed that both of them had disappeared from my project folder. However, I was not getting any .dll missing errors. Replacing them in the folder didn't solve the problem, but I am wondering if their disappearance has something to do with this. They are also located in the VC/bin/ directory of the VS2010 install path, and deleting them from both locations produces the error message, but having them in either location is now sufficient for building and running when previously I needed them in both.
One possibility is that you're scaling by an infinite value (1.#INF), or something of the sort. I've run into a very similar situation, and that turned out to be the problem. However, if you have not changed the code, then you may be able to rule this out. Have you tried throwing in some code to render a simple quad or triangle to the screen?
As for the .dlls, I recommend putting them in your C:/Windows/SysWOW64 and C:/Windows/System32 folders. SysWOW64 specifically houses all the 32-bit .dlls, but it's safe to put them in both locations. Visual Studio will look in both your project folder and these system folders for necessary dynamic libraries. The advantage of placing them in the system folders is that they are then available for all OpenGL applications you may write.
One last thing that might help in finding the issue is making use of OpenGL's error reporting. You can use a function such as:
void HandleGLError()
{
GLenum error;
int i = 0;
while ((error = glGetError()) != GL_NO_ERROR) {
printf("GL ERROR(%d) %s\n",i,gluErrorString(error));
i++;
}
}
Try calling that at the beginning and end of your render function, and in any other places you think might be causing a problem.
Alright, I presented this question on the MSDN forums but have yet to receive any kind of response so I figured I'd give StackOverflow a try.
I'm currently developing a DirectX application using VS2008 on Win7. I recently experienced a nasty memory corruption bug with a memory allocation class that grabbed byte aligned memory. During this bug I could still run the debug and release executables however it would crash due the instructions getting corrupted or whatever, but it would still execute for a bit until the crash.
I then stripped out the entire memory allocation class. The application runs perfectly in the IDE (release and debug builds) but I can't run any of the executables at all. They immediately crash with a non-responding/stop working error. And I don't think it is my environment because I get the same issue on another computer that wasn't having problems before either.
Dependency walker gives a "Warning: At least one delay-load dependency module was not found. Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module." error and indicates that GPSVC.dll and IESHIMS.DLL can't be found. I've read that this can be misleading and just indicates a potential problem somewhere. And Dependency walker wasn't giving me this error the day before.
I haven't tinkered with any of the configuration or project settings or added new code. Any idea of what could be causing this behavior?
Also another note, I installed the Windows 7.1 sdk the same day. Think this could be some kind of compiler related bug?
Just in case some useful information pops up on the MSDN post, here is the link
http://social.msdn.microsoft.com/Forums/en-IE/vsdebug/thread/f692b394-8af2-4453-991c-aa6a443a9019
Thanks!
Edit -
Here is the last couple lines of Dependency Walker's profiling output
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAE4F and returned 0x77B59D65.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAE4F and returned 0x77B59D65.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "EncodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAF60 and returned 0x77B60FDB.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAF70 and returned 0x77B59D65.
Second chance exception 0xC0000005 (Access Violation) occurred in "c:\users\joel\desktop\DXAPP.EXE" at address 0x0110152E.
Exited "c:\users\joel\desktop\DXAPP.EXE" (process 0x27D8) with code 255 (0xFF).
Is this referring to a DLL grabbing a null pointer or to my actual instructions? Going to read up on how to use WinDbg real quick and I'll post it's output if this doesn't shed any immediate light on the issue.
Edit 2 -
Simply running the application and hitting debug to bring up Visual Studio consistently brought me to where I'm compiling my shaders. I'm assuming at the moment that the root of the problem lies around this. However, I still don't understand the change of behavior during execution between using the IDE and not.
Solution! -
I was so thrown off by the previous memory corruption bug that I didn't realize my shaders weren't in a local directory to the executables. This in turn was generating a null pointer that wasn't handled properly after calling D3DX11CompileFromFile().
Shoot, sorry I meant to post this as a comment...
I can only suggest more diagnostic attempts.
One would be to profile the app from within Depends, this will also show dynamic DLL loads and might show something new. Also it captures the debug output. It may behave differently than launching in the debugger itself and provide a clue. You don't mention actually profiling so I thought I'd suggest it in case you hadn't. Also, pay very close attention to the paths for the DLL's loaded - you might be surprised at a DLL loading from a location other than you intended.
Another suggestion is to try at attach to the stopped app after the crash (before dismissing the error dialog). See if you can get a stack trace or anything out of it.
Finally try attaching (or even launching from) WindDbg rather than the IDE. Like the Depends profile, the difference in debugger behavior and how it hooks the app may allow the crash to happen, while providing the clues you need.
Good Luck!