Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 5514
  • Last Modified:

Fault in msvcr90.dll

I am working with an application, and I get a fault in the application log that states:  Faulting application (application, version), faulting module msvcr90.dll, version 9.0.30411.0, fault address 0x0002464c.  Is there any way to tell what's at that address so I can start narrowing down what's wrong here?
0
Paladine_42
Asked:
Paladine_42
  • 5
  • 4
  • 2
  • +2
1 Solution
 
abelCommented:
Yes, you can. Open Visual Studio and select Debug > Attach To Process. When the error occurs, it will break in Visual Studio and you can see the disassembly. If you have debugging symbols installed, you can see the meta information (if available) as well.
0
 
abelCommented:
There are quite some reports on the internet about this message, but not sure if you checked them. Since versions differ, address differ: a google search
0
 
Paladine_42Author Commented:
well, i don't have the source for this particular program.  I was hoping there was a way to check with something like dependancy walker or similar to see whats erroring.  

How about this, how would i get a list of functions in that particular dll?
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
jkrCommented:
>>How about this, how would i get a list of functions in that particular dll?

You can get one with the Dependecy Walker. Now, the problem is that this faulting address is absolute, whereas the the functions' addresses within the DLL are relative to the base load address. That one you'll be able to get when you run that app in Dependecy Walker's "Profile Mode". So you could figure out which function exactly causes the crash, but I am afraid that this won't get you very far.
0
 
abelCommented:
You really should try to attach Visual Studio to the running process (or WinDbg, if you do not have visual studio). You can also download, for free, the debugging symbols. The combination of these two will give you enough information of where it goes wrong (but not necessarily a why).

If you think it is related to some win32 api call, you can also use one of the many API monitors to check which APIs are being called (use the tip from jkr to find this out).

Finally, it is a good idea to run the DebugViewer from sysinternals. If there are any debugging statements in the dll (again, you should request a checked build) then you will find them with this too.
0
 
evilrixSenior Software Engineer (Avast)Commented:
You could use DebugDiag or UserDump (both free debugging tools from Microsoft) to monitor the process and create a userdump file when it crashes. This will contains a full stacktrace of the faulted module and precise details of why it crashed as well as the memory being preerved so you can perform post-mortum analysis. You might want to consider looking at this.

"How to use the Userdump.exe tool to create a dump file"
You can use the Userdump.exe tool to generate a user dump of a process that shuts down with an exception or that stops responding (hangs).
Includes link to download
http://support.microsoft.com/kb/241215

"Debug Diagnostic Tool v1.1"
The Debug Diagnostic Tool (DebugDiag) is designed to assist in troubleshooting issues such as hangs, slow performance, memory leaks or fragmentation, and crashes in any Win32 user-mode process.
http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en
0
 
itsmeandnobodyelseCommented:
The msvcr90.dll contans enhancements of the VC runtime functions new in VC9.0 (== VC compiler of Visual Studio 2008). Though it is not impossible that there is a bug somewhere it is rather unlikely. Much more likely is that you call implicitely one of these runtime functions with a wrong argument, e. g. a wrong pointer. If for example you use strcpy with a NULL pointer as first argument, the strcpy could call strcpy_s which is in msvcr90.dll and that would die because of the NULL pointer.

So, I wouldn't debug the msvcr90.dll but debug my own application. I would set all exceptions, especially 'access violation' to 'break immediately', so taht in case of the crash you could see in the call stack which of your own functions has caused the error. You can make that settings in the menu Debug - Exceptions - Win32 Exceptions. Here for each exception type you can specify whether the debugger should break immediately or gives your call hierarchie the chance to catch and handle the exception. The latter is the default and unfortunately obliterates any hints where the initial error occured.

If you can't debug or can't reproduce the crash in debug mode, you could put message boxes at begin and end of each possible function where the crash may occur. If you got the begin message but not the end message you can narrow the message boxes until you know the statement where it crashes. Then, check all the variables, calls and arguments used in that context (don't forget the this pointer if you are in a class member function). If it crashes at end of a function or block with no significant statement, check the class objects defined in that scope and thier destructors. If for example a member pointer was copied between objects and the destructor deletes that pointer, the second object would crash for that action.

0
 
abelCommented:
excellent points, evilrix and itsmeandnobodyelse. One additional tip to the OP, instead of:

> you could put message boxes at begin and end of each possible function where the crash may occur.
use OutputDebugWrite and catch that output with DebugView. That way you can sit back and watch the error occur without having to click away all those message boxes.
0
 
evilrixSenior Software Engineer (Avast)Commented:
>> excellent points, evilrix and itsmeandnobodyelse.
Thank you sir :)
0
 
evilrixSenior Software Engineer (Avast)Commented:
BTW: If you do generate a crash dump, do feel free to post it here and I'd be happy to analyse it for you (yes, I'm a sad geek who enjoys crash dump analysis -- I need to get out more, eh?).
0
 
abelCommented:
(you didn't take my comment as one from the OP, did you, evilrix? Sorry for the confusion, if so... )
0
 
evilrixSenior Software Engineer (Avast)Commented:
>> you didn't take my comment as one from the OP, did you, evilrix?
No, of course not... experts still deserve curtsey, right?
0
 
itsmeandnobodyelseCommented:
>>>> use OutputDebugWrite and catch that output with DebugView

The message boxes were for the case that the error doesn't show up in debug mode ;-)
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 5
  • 4
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now