BTW: The ntldll is where the problem manifests (because it's probably failing in a system call) but the problem is going to be in the code making the system call.
Main Topics
Browse All TopicsHello
I have an application written in VC++ 6.0 that is intermittently failing (both running on XP Pro and 2003 Server.) When it does it produces an error in the event log:
faulting module ntdll.dll, version 5.2.3790.4455 (it goes on to list my application name and a memory address).
How might I got about tracking the source of this?
Thanks!
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
>>>> is intermittently failing (both running on XP Pro and 2003 Server.)
If you can't reproduce the crash in the debugger (where you could examine the call stack to spot *your* code which makes the wrong call), you might add trace code to the program in order to locate the last function call before crashing. You could use a helper class like the below for tracing:
class Trace
{
static std::string logfile;
std::string where;
public:
static void setLogfile(const char* lf) { logfile = lf; }
Trace(std::string w) : where(w)
{
std::ofstream log(logfile.c_str(), ios::out | ios::app);
if (log)
{
log << "Entering " << where << std::endl;
log.close();
}
}
~Trace()
{
std::ofstream log(logfile.c_str(), ios::out | ios::app);
if (log)
{
log << "Leaving " << where << std::endl;
log.close();
}
}
};
Use the above by simply adding a Trace instance to each function which might die:
void AnyClass::anyFunc()
{
Trace trace("AnyClass::anyFunc")
// here begins your current code
...
}
In a multi-threading environment you would need to make the logging thread-safe by using a critical_section object. You also could add a static trace threshold which would allow to control the amount of loggings (best changeable at runtime).
If after crash you see 'Entering' log messages but not corresponding 'Leaving' messages, you could narrow down the Trace messages until you caught the pulprit.
Business Accounts
Answer for Membership
by: evilrixPosted on 2009-09-16 at 09:38:18ID: 25347491
>> How might I got about tracking the source of this?
om/kb/2412 15 OWNLOADS/d etails.asp x? FamilyID =28bd5941- c458-46f1- b24d-f6015 1d875a3&di splaylang= en hdc/DevToo ls/Debuggi ng/ default .mspx hdc/devtoo ls/debuggi ng/ install x86.Mspx
Well, either try and make it crash in the debugger in debug build or try to use userdump or debugdiag to force it to produce a crash dump. Use WinDBG to analyze that crash dump and post the analysis here.
http://support.microsoft.c
http://www.microsoft.com/D
http://www.microsoft.com/w
http://www.microsoft.com/w