I am currently working on moving our multi-threaded server app fom VS2013 to VS2017. The port was straightforward enough however i have encountered a weird issue with our use of JNI.
We load the jvm.dll dynamically and then do a GetProcAddress for JNI_CreateJavaVM; this code has worked robustly in VS2013 however in VS2017 i am unable to step over the call to the create JVM function without it reporting a null ptr exception.
Whats wierd is that if i then hit continue to the next break point i find my call to create JVM has succeed and i can then go on to call JNI function to create classes etc.
Anyone got a remedy for this - is it a known issue ?
In VS2017 goto
Exception Settings - (Ctrl + Alt + E)
and in Win32 exceptions tick 0xc0000005 Access violation.
JVM generates the mentioned exception when it startups to check OS features. So you can ignore it and move forward.
Related
I've started getting the following exception while debugging a 32bit MFC C++ app under VS2010 SP1, Windows 7 64. While I can easily ignore it, I'm just wondering what it is.
First-chance exception at 0x751eb9bc in SCCW.exe: 0x80010108: The
object invoked has disconnected from its clients.
A similar question and a google search suggest its automation related, and while my app supports automation, it isn't doing anything automation related at the time. The stack frame for the active thread does not show anything much, all system DLLS (ntdll.dll,rpcrt4.dll,ole32.dll). I've been debugging the same app on the same system for a long time and only started seeing this recent, so just wondering why. Any ideas, and can it be safely ignored?
This will be some other executable that gets loaded in. It could be something that has windows hooks etc such as a virus scanner, or it could be a shell extension. Look up what SCCW is. If it is something you don't need on your system, uninstall it.
It should be safe to ignore, and you can prevent the application from stopping in the debugger by adding the exception type and telling VS not to stop on it.
Debug | Exceptions...
Then under Win32 Exceptions untick "80010108 Server Disconnected from clients".
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!
I am using the debug_new tool that come in the pack of tools NVWA made by Wu Yongwei. http://wyw.dcweb.cn/
I turned it off once to track a heisenbug, that now is fixed. But as I turned it on, my program throws a bizarre error:
It loads, but before accepting any input it quits and writes on the console:
"This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information
Process returned 3 (0x3) execution time : 0.828s"
How I debug that? I have no idea what on the code is throwing the error (since when using a debugger it still quits the same way, and the debugger reports no errors with exit of the debugger being 0)
EDIT for those that don't read tags: I am using C++, compiling with MingW on Windows.
If you're running under the Visual Studio debugger, go to the Debug/Exceptions menu and check the box for the "C++ Exceptions" item - this will cause the debugger to break whenever an exception is thrown.
You might need to fiddle with the various sub-options (std:exception, void, etc) for the exception types if your code throws a lot of exceptions that it catches and you're not interested in breaking into the debugger when they get thrown.
KB884538 -- try installing the hotfix.
I am writing a C++ COM object in Visual Studio 2008 that is an Internet Explorer Browser Helper Object. Recently, when running in IE, IE has started frequently popping up a dialog titled "Microsoft Visual C++ Runtime Library" with an error message "Runtime Error!" and going on to say that "The application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information." Unlike usual, this dialog only has an OK button but no debug button, so IE then terminates and I'm not left with so much as a stack trace or even a hint of what part of my code could have been so buggy. I'm not sure where in my code it is crashing.
How does one troubleshoot a "Runtime error" problem? What are possible causes of a runtime error? (memory related bugs perhaps?) What sort of problems should I be checking my code for to attempt to eliminate this sort of crash? I need some ideas on how to troubleshoot this one, its a bit elusive.
When you see that dialog, start VS2008 with your COM object project.
Then use the menu Debug->Attach to process to attach the debugger to the IE process which has your COM object loaded.
Then break into the process (Debug->break all) and you get the stack trace.
It bombs due to an unhandled exception. That gives you a chance to make the debugger stop on the first chance exception, right at the point where it is raised. Open your project, make iexplorer.exe the startup program. Debug + Exceptions, check the Thrown flag on the unmanaged exceptions. Make it crash to get the breakpoint.
I have a Windows application written in C++ that occasionally evaporates. I use the word evaporate because there is nothing left behind: no "we're sorry" message from Windows, no crash dump from the Dr. Watson facility...
On the one occasion the crash occurred under the debugger, the debugger did not break---it showed the application still running. When I manually paused execution, I found that my process no longer had any threads.
How can I capture the reason this process is terminating?
You could try using the adplus utility in the windows debugging tool package.
adplus -crash -p yourprocessid
The auto dump tool provides mini dumps for exceptions and a full dump if the application crashes.
If you are using Visual Studio 2003 or later, you should enable the debuggers "First Chance Exception" handler feature by turning on ALL the Debug Exception Break options found under the Debug Menu | Exceptions Dialog. Turn on EVERY option before starting the debug build of the process within the debugger.
By default most of these First Chance Exception handlers in the debugger are turned off, so if Windows or your code throws an exception, the debugger expects your application to handle it.
The First Chance Exception system allows debuggers to intercept EVERY possible exception thrown by the Process and/or System.
http://support.microsoft.com/kb/105675
All the other ideas posted are good.
But it also sounds like the application is calling abort() or terminate().
If you run it in the debugger set a breakpoint on both these methods and exit() just for good measure.
Here is a list of situations that will cause terminate to be called because of exceptions going wrong.
See also:
Why destructor is not called on exception?
This shows that an application will terminate() if an exceptions is not caught. So stick a catch block in main() that reports the error (to a log file) then re-throw.
int main()
{
try
{
// Do your code here.
}
catch(...)
{
// Log Error;
throw; // re-throw the error for the de-bugger.
}
}
Well, the problem is you are getting an access violation. You may want to attach with WinDBG and turn on all of the exception filters. It may still not help - my guess is you are getting memory corruption that isn't throwing an exception.
You may want to look at enabling full pageheap checking
You might also want to check out this older question about heap corruption for some ideas on tools.
The most common cause for this kind of sudden disappearance is a stack overflow, usually caused by some kind of infinite recursion (which may, of course, involve a chain of several functions calling each other).
Is that a possibility in your app?
You could check the Windows Logs in Event Viewer on Windows.
First of all I want to say that I've only a moderate experience on windows development.
After that I think this is a typical case where a log may help.
Normally debugging and logging supply orthogonal info. If your debugger is useless probably the log will help you.
This could be a call to _exit() or some Windows equivalent. Try setting a breakpoint on _exit...
Have you tried PC Lint etc and run it over your code?
Try compiling with maximum warnings
If this is a .NET app - use FX Cop.
Possible causes come to mind.
TerminateProcess()
Stack overflow exception
Exception while handling an exception
The last one in particular results in immediate failure of the application.
The stack overflow - you may get a notification of this, but unlikely.
Drop into the debugger, change all exception notifications to "stop always" rather than "stop if not handled" then do what you do to cause the program failure. The debugger will stop if you get an exception and you can decide if this is the exception you are looking for.
I spent a couple hours trying to dig into this on Visual Studio 2017 running a 64-bit application on Windows 7. I ended up having to set a breakpoint on the RtlReportSilentProcessExit function, which lives in the ntdll.dll file. Just the base function name was enough for Visual Studio to find it.
That said, after I let Visual Studio automatically download symbols for the C standard library, it also automatically stopped on the runtime exception that caused the problem.