this is just a question for my interest.
Is it possible that my c++ application is crashing and throwing an access violation because windows is not activated?
I tested the program on several systems and everything works fine, but when I test it on a virtual machine where a windows is not activated it crashes and throws this exception.
Could there be any correlation between it?
Thank you for helping.
I see no correlation with Windows not being activated, in this case it should give a comprehensible enough error, but you have two variables here:
Windows is not activated
You have a virtual machine
Other than running a debugger like others suggested, I'd troubleshoot the problem running your program on a real machine with a window not activated and in a virtual machine with an activated window.
Chances are that the problem is the virtual machine itself and not window not being activated.
Related
I have a c++ program compiled with MinGW which links to libmicrohttpd to run a webserver. It normally functions correctly, but I am trying to do some robustness testing and for my current test I have tried to disable the network interface. This results in the program crashing with the dialog box: "MyProgram.exe has stopped working - A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."
Rather than debug the program and potentially its dependencies, for my purposes, it would be fine if it would just crash silently without making the dialog box (I have another component that is meant to restart it). Is this possible to do via some sort of manifest or Windows API call?
It turns out there is a Windows API function called SetErrorMode. Passing the parameter SEM_NOGPFAULTERRORBOX will prevent the error dialog from being displayed on a crash.
There is also the RegisterApplicationRestart function which can be used to have Windows restart an application in the event of a crash (or other configurable reasons).
We are using QTcpServer and QSslSocket for server-client communication. Witnessing a crash once in a while in one particular Windows machine. Unfortunately in this machine, we don't have a debugger. Hence I could get the stack frame only with the "Process Explorer" utility from Windows. Here is the image:
Documentation for WSHStringToAddress function suggests that it's obsolete. This crash is not seen elsewhere.
How to resolve this issue?
After debugging we found out that, WSHStringToAddress() is not a troublemaker, though obsolete. It's seen in the healthy app running as well as a "thread".
The root cause was within our code where there was an infinite recursion. Somehow, due to lack of stack frames, it was not seen properly with the above MS tool.
The problem
There seems to be a problem with my application, because it crashes unexpectedly. I'm trying to solve the problem, but I have the following problem:
On Windows 7, when the application crashes, instead of getting some useful information about the crash, the following window appears:
The question
Is it possible to make Windows (7) show some actual useful information? Like a stack trace? Memory dump? A weird error code? Anything? I highly doubt Microsoft can help me here... in fact, checking for a solution to the problem never found a solution for any application, I don't know why this window even exists.
I remember that on Windows XP, there was that Error report window, and somewhere there was a link to another window which actually displayed some information.
What I tried
I tried to handle application crashes myself, using signal handling. However signal handling using MinGW seems to be pretty broken: writing to a null pointer should send a SIGSEGV signal, but the program crashed. Looking up on the internet, I found this thread which led me to believe that signal handling may be broken.
Using GDB with multiple threads is giving me a lot of trouble, since there is some time-sensitive stuff being done.
Other note(s)
I am working on Windows 7 (obviously), using the MinGW compiler suite, Eclipse IDE.
when this window appears, don't click Cancel. About 1 or 2 minutes later it will become another window that allow you choose a specified compiler(on my computer it's visual studio 2010) and debug.
When I debug a large app (with VS2008) that I maintain on a Windows 7 Hyper V VM, it seems that once I hit a breakpoint, VS constantly throws 0xC0000096 Privileged instruction exceptions( or 0x00000005 Access violation reading 0x03A6E7EB).
It doesn't seem to matter where the breakpoints are set either. I can do exactly the same things on a Win2k3 box with VS2008 installed, but never get these faults. The code & the settings are the same. When I first installed VS2008 & compiled & debugged the app these exceptions weren't being thrown - it only started happening after a couple of weeks. Is this a Hyper V/virtual machine issue or what?
There's not much point supplying any code as it seems independent of that, though if any more info is needed I'll try to supply it.
Your answer may be here: Debugging commands (step over/into) cause unhandled exceptions
Uncheck the "Enable RPC Debugging" option in Tools->Options->Debugging->Native
My application crashes with an error saying "Demo Application pk/si component has stopped working". The systems Event Viewer log shows an error with the following details.
"Faulting application Demo.exe, version 1.0.0.1, faulting module OLEACC.dll,version 4.2.5406.0, time stamp 0x4549bd93,exception code 0xc0000005,fault offset 0x00004062,process id 0x154c,application start time 0x01c9ee94aab4c550"
I am using Windows Vista Home Premium edition and the application which i created was a Vc++ SDI application.
Please let me know if anyone have come across this issue and what could be the possible solution for the same.
Thanks in Advance,
It looks like good old access violation to me. It looks like you writing/reading from an invalid memory location in your application.
It's most likely a bug somewhere in your code that is passing invalid values to some Windows functions, and somewhere further down the line this results in a crash. Just because it isn't your DLL where the crash occurs doesn't mean it isn't your fault!
Although this isn't very helpful, all you can do is hook up a debugger to your program and reproduce the crash, then debug it.