I have created a program which runs 2 threads synchronized using events (SetEvent(), WaitForSingleObject(), WaitForMultipleObjects()) in Visual Studio 2010. The following happens:
when I run this program using the debugger it runs for a certain time and then crashes
when I run this program without debugging (.exe file) it crashes directly
when I run this program in another computer using the debugger it crashes immediately and via .exe file it crashes after some time
The following error has been reported when debugging:
Unhandled exception at 0x5eafcaf7 (msvcr100d.dll) in test.exe: 0xC0000005: Access violation reading location 0x0036f000.
Could somebody bring some light to this topic as I don't know where to start searching? Which is the difference between running the code in the debugger or without? (Which kind of code is added?) Why do the different computers have different behaviours when running the same code?
In both computers there is exactly the same operating system (Windows 7) and I assume the same libraries and patches.
Thank you for your help!
EDIT 11.12.2012
I have installed Application Verifier and get in Visual Studio some errors displayed as this:
===========================================================
VERIFIER STOP 0000000000000013: pid 0x1E18: first chance access violation for
current stack trace
000000000874F000 : Invalid address being accessed
000000005201CAF7 : Code performing invalid access
000000000009E440 : Exception record. Use .exr to display it.
000000000009DF50 : Context record. Use .cxr to display it.
===========================================================
Does somebody know how I can see which address belongs to which line of code to know exactly where the exception occurs? I have also read in the Help of the program that using the command "!heap p -a ACCESS_ADDRESS" should give details about the nature of the error and what heap block is overrun. Where should I place this command using Visual Studio?
When working in a multi-threaded environment, things can happen at different speeds on different threads. Trying to identify the possible cause without the relevant code is quite difficult.
The error is a general memory access violation error. This usually occurs when a variable being returned from a function is bigger than expected, or different type.
Can we see the code please?
Related
TwinCAT crashes every now and then with the following message in the eventlog
Debug: CSysService::SysUnhandledExceptionFilter(); Addr:770A2092 Code:C0000005
Search on Google reveals nothing about why this is happening, how to troubleshoot this or even what CSysService is or what the SysUnhandledExceptionFilter method is doing. My guess is that an access violation is happening which is unhandled.
I'm hoping that someone here can help me determine if this is caused by our own code or if this is a problem of TwinCAT itself. And hopefully get some pointers on how to get this resolved.
I tried reproducing this by creating an access violation in code. This however shows a different log message.
You are providing too few informations.
Which Twincat version are you using?
Does it crash while doing some specific operations
(For example pressing a button in the visualization or while doing online change)?
How often does it crash?And since when?
We are using TwinCAT 3.1.4022.28. The crashes don't seem to be related to a use case. At one point it crashed during the night while nobody was operating it. It crashes at random intervals, typically multiple days apart. We have seen about 4 to 5 crashes till now.
On codeguru.com there is an article about the CSysService class and it states:
CSysService is a C++ class which wraps methods around several of the
Win32. API service functions, providing an object-oriented interface
to these functions, grouping common variables and structures in a
single class object. The result is an extensible base class capable of
installing, enumerating, modifying, controlling and removing a service
application in the Service Control Manager.
It means it is an Exception raised by the Win32 API.
On the Beckhoff infosys website you can find the Win32 error codes and their meaning:
https://infosys.beckhoff.com/index.php?content=../content/1031/TcDiagnostics/HTML/TcDiagnostics_WIN32_ErrorCodes.htm&id=
The 0x00000005 error means access denied.
If you take a look at this error on the microsoft support page:
https://support.microsoft.com/en-us/help/842792/an-error-access-denied-error-occurs-when-you-try-to-write-to-a-file-th
you will find out that this error happens when:
you try to write to a file that is in a network shared folder
Your plc is probably trying to write a logfile located in a network shared folder to which it may not always have access to, causing the runtime to crash unexpectedly.
(A network maintenance during the night could explain the access denial and the consequent exception on your machine).
If this is the cause of the problem, please inform the Beckhoff support so that they can investigate it further and maybe fix it in a future release.
I have a Visual Basic 4 32 bit application which results in a
Run-time error '5':
Invalid procedure call
I start WinDbg and do
sxe *
to break on all exceptions. However, it displays the message without breaking into the debugger before.
If I break at the time of the message, the callstack is not very useful. Is there a trick to break-in on Visual Basic 4 applications at the time the problem occurs?
Problem FAQ:
Can you run it in the IDE?
Yes I can and I can probably fix the bug when I do that. However, I'd like to get some more information at the time the end user runs the application so that I don't need to be able to reproduce it.
What do you want to do in case you find the cause of the error?
Well, it depends on the type of the error. Maybe I can fix it, maybe I can't. Usually I get some very helpful information out of WinDbg.
When does the error occur?
It occurs reproducibly when the user presses a close button on a form.
What does the application do?
Oh, that's a good question. I don't exactly know. It uses RS232 communication but it's not yet involved.
Do you know anything about the data the user can enter?
I almost know nothing about it. In this particular case, it's not necessary to enter data.
The error is from the VB virtual machine not from an API.
I can't see how WinDbg would be useful on VB4 which is interpreted and is in P-Code.
Visual Basic run-time error 5 Indicates one of the following:
An invalid collection or property name was entered.
An out parameter was NULL.
The value is not one of the supported values or falls outside the supported range.
The property is read-only.
The property cannot be changed after the object is created.
An invalid index was entered.
And in case it's an API call VB uses LoadLibrary and GetProcAddress.
Some controls have lost default values over time and this can cause the first.
The third can happen if modern technology exceeds the program's expection, e.g. disk space.
Also see (sorry no links, they are on my hard disk)
Q131007 HOWTO: Use Windows NT WinDbg.exe with Visual Basic (it's for NT 3.5)
Q166275 HOWTO: Debug a Native Code Visual Basic Component in VC++ (talks about what you can see in VB in a debugger)
VB4 can't make symbols
As the error occurs when the users presses the close button i assume there is a (very tight) loop running which doesn't receive the expected data (probably a nullstring)
I expect that that loop is continuously reading data from the RS232 device and the RS232 is on the form which is being closed, even though it is not involved the connection might already be open and polling
What you should do is exit that loop and close the connection with the RS232 device before closing the form. You might be able to do that in the Form_Unload() event, but it might also have to take place before that, so you might have to do it in the code of the close button ... make sure though that the user won't be using the X to close the form though
Personally i would run the program from within the IDE, this will point you to the errornous part of the code directly and gives you the opportunity to watch the contents of the variables involved and control states ... that is much faster than taking a guess based on the data of WinDbg
I have a customer who is getting a 100% reproduceable crash that I can't replicate in my program compiled in Visual Studio 2005. I sent them a debug build of my program and kept all the PDB and DLL files handy. They sent me the minidump file, but when I open it I get:
"Unhandled exception at 0x00000000 in MiniDump.dmp: 0xC0000005: Access violation reading location 0x00000000."
Then the call stack shows only "0x00000000()" and the disassembly shows me a dump of the memory at 0x0. I've set up the symbol server, loaded my PDB symbols, etc. But I can't see any way of knowing which of the many DLLs actually caused the jump to null. This is a large project with many dependencies, and some of them are binaries that I don't have the source or PDBs for, as I am using an API as a 3rd party.
So how on earth is this minidump useful? How do I see which DLL caused the crash? I've never really used minidumps for debugging before, but all the tutorials I have read seem to at least display a function name or something else that gives you a clue in the call stack. I just get the one line pointing to null.
I also tried using "Depends" to see if there was some DLL dependency that was unresolved; however on my three test machines with various Windows OS's, I seem to get three different sets of OS DLL dependencies (and yet can't replicate the crash); so this doesn't seem a particularly reliable method either to diagnose the problem.
What other methods are available to determine the cause of this problem? Is there some way to step back one instruction to see which DLL jumped to null?
Well it looks like the answer in this instance was "Use WinDbg instead of Visual Studio for debugging minidumps". I couldn't get any useful info out of VS, but WinDbg gave me a wealth of info on the chain of function calls that led to the crash.
In this instance it still didn't help solve my problem, as all of the functions were in the 3rd party library I am using, so it looks like the only definitive answer to my specific problem is to use log files to trace the state of my application that leads to the crash.
I guess if anyone else sees a similar problem with an unhelpful call stack when debugging a minidump, the best practice is to open it with WinDgb rather than Visual Studio. Seems odd that the best tool for the job is the free Microsoft product, not the commerical one.
The other lesson here is probably "any program that uses a third party library needs to write a log file".
The whole idea behind all 'simple' ways of post mortem debugging is the capture of a stack trace. If your application overwrites the stack there is no way for such analysis. Only very sophisticated methods, that record the whole program execution in dedicated hardware could help.
The way to go in such a case are log files. Spread some log statements very wide around the area where the fault occurs and transmit that version to the customer. After the crash you'll see the last log statement in your log file. Add more log statements between that point and the next log statement that has not been recorded in the log file, ship that version again. Repeat until you found the line causing the problem.
I wrote a two part article about this at ddj.com:
About Log Files Part 1
About Log Files Part 2
Just an observation, but the the stack is getting truncated or over-written, might this be a simple case of using an uninitialised field, or perhaps a buffer overrun ?
That might be fairly easy to locate.
Have you tried to set WinDbg on a customer's computer and use it as a default debugger for any application that causes a crash? You just need to add pdb files to the folder where your application resides. When a crush happens WinDbg starts and you can try to get call stack.
Possibly you already know this, but here are some points about minidump debugging:
1. You need to have exactly the same executables and PDB files, as on the client computer where minidump was created, and they should be placed exactly in the same directories. Just rebuilding the same version doesn't help.
2. Debugger must be connected to MS Symbols server.
3. When debugger starts, it prints process loading log in the Output window. Generally, all libraries should be successfully loaded with debug information. Libraries without debug information are loaded as well, but "no debug info" is printed. Learn this log - it can give you some information.
If executable stack contains frames from a library without debug information, it may be not shown. This happens, for example, if your code is running as third-party library callback.
Try to create minidump on your own computer, by adding some code which creates unhandled exception, and debug it immediately. Does this work? Compare loading log in successful and unsuccessful debugging sessions.
You may have called null function pointer. Current executing function information is needed to show call stack information. Force set instruction pointer to start of any simple function, then you'll see call stack information again.
void SimpleFunc()
{ // <- set next statement here
}
An error occure saying:
Unhandled exception at 0xfeeefeee in sgdoc.exe: 0xC0000005: Access violation reading location 0xfeeefeee.
While transferring application from VC++ 6.0 to Visual Studio 2005.
Please help me out.
Your program is trying to read from the address 0xFEEEFEEE.
Since this pattern is the marking free'd memory, your program is probably trying to access a pointer inside a struct that has already been deleted.
You will have to let your program crash with a debugger attached and look what is going on before the crash happens.
Without more data I'll venture 2 guesses.
some memory that was previously initialized with 0 is left uninitialized or is initialized with something else. Check your memory allocation and usage patterns.
I'm assuming you're using mfc, maybe something changed in the implementation since vc6. Try taking chunks out of your class declarations and see if you can identify the problem like that.
What would help more is the lines around the place where the crash happens, and any related declarations that pertain to that bit of code.
Every now and then (ahem...) my code crashes on some system; quite often, my users send screenshots of Windows crash dialogs. For instance, I recently received this:
Unhandled win32 exception # 0x3a009598 in launcher2g.exe:
0xC00000005: Access violation writing location 0x00000000.
It's clear to me (due to the 0xc0000005 code as well as the written out error message) that I'm following a null pointer somewhere in my launcher2g.exe process. What's not clear to me is the significance of the '0x3a009598' number. Is this the code offset in the process' address space where the assembler instruction is stored which triggered the problem?
Under the assumption that 0x3a000000 is the position where the launcher2g.exe module was loaded into the process, I used the Visual Studio debugger to check the assembler code at 0x3a009598 but unfortunately that was just lots of 'int 3' instructions (this was a debug build, so there's lots of int 3 padding).
I always wondered how to make the most of these # 0x12345678 numbers - it would be great if somebody here could shed some light on it, or share some pointers to further explanations.
UPDATE: In case anybody finds this question in the future, here's a very interesting read I found which explains how to make sense of error messages as the one I quoted above: Finding crash information using the MAP file.
0x3a009598 would be the address of the x86 instruction that caused the crash.
The EXE typically gets loaded at its preferred load address - usually 0x04000000 iirc. So its probably bloody far away from 0x3a009598. Some DLL loaded by the process is probably located at this address.
Crash dumps are usually the most useful way to debug this kind of thing if you can get your users to generate and send them. You can load them with Visual Studio 2005 and up and get automatic symbol resolution of system dlls.
Next up, the .map files produced by your build process should help you determine the offending function - assuming you do manage to figure out which exe/dll module the crash was inside, and what its actual load address was.
On XP users can use DrWatsn32 to produce and send you crash dumps. On Vista and up, Windows Error Reporting writes the crash dumps to c:\users\\AppData\Local\Temp*.mdmp