Getting "Unhandled exception" error when running in IDE

[Peter Steele]

We have an application that when it runs in the IDE in debug mode an
unhandled exception is occurring in a system header file associated with STL
stirngs. The actual statement that crashes is

return ::memcmp(_First1, _First2, _Count);

On inspecting these variables, the strings are in fact equal when the
exception occurs and _Count is the right size. As a test I replaced this
code in the system include file with a for loop to do the comparison, and
after doing this the exception *still* occurs. It doesn't report anything
about the exception, other than the dialog "Unhandled exception". If we run
this same app outside of the IDE we do not see this error. What's going on
here anyway?

 

[Guest]

You are going to have to narrow it down. The first thing I would try is to
compare zero characters and see if the exception still occurs.

return ::memcmp(_First1, _First2, 0);

Then go up incrementally by 1 until the error occurs. If it occurs right
away on the first or second character then make sure you are passing in the
right values, now I have never used the STL string class but make sure it is
actually passing in the correct pointer, in other words that it is passing in
an ANSI string pointer instead of UNICODE or whichever is the correct one.
Like I said I have never used this string class so you know more than I do.

mosimu

 

[Peter Steele]

I believe this STL routine is used when comparing strings and it gets called
various other times without exceptions occurring. When the exception does
occur, the call stack has several instances of ntdll.dll on it but does not
show the functions in our code that lead to the point of the crash. Based on
the content of the strings are the time the exception occurs I can narrow
down where the STL comparison likely took place. I might try changing it to
using C string comparison instead of STL string comparison and see what
happens.

 

[Oleg Starodumov]

I believe this STL routine is used when comparing strings and it gets called
various other times without exceptions occurring. When the exception does
occur, the call stack has several instances of ntdll.dll on it but does not
show the functions in our code that lead to the point of the crash. Based on
the content of the strings are the time the exception occurs I can narrow
down where the STL comparison likely took place. I might try changing it to
using C string comparison instead of STL string comparison and see what
happens.

What call stack do you see? It is possible that symbols for system DLLs
are not available; then if you obtain good symbols (e.g. from symbol server),
it will be possible to see a much better call stack.

Also, if the application is running under debugger, presence of ntdll.dll functions
on the call stack after exception often means that there is a heap corruption.

Regards,
Oleg

 

[Peter Steele]

Although the exception always occurs on a memcmp call in the STL header file
iosfwd in the function compare, the call stack isn't always the same. Most
of the time however it looks like this:

ntdll.dll!7c901230()
ntdll.dll!7c96c943()
ntdll.dll!7c949eb9()

mcsTunnel.exe!std::char_traits<char>::compare(const char *
_First1=0x00d17148, const char * _First2=0x00e1f55c, unsigned int
_Count=12) Line 347 + 0x11 C++

::compare(unsigned int _Off=13697024, unsigned int _N0=0, const char *

_Ptr=0x00d10000, unsigned int _Count=12) Line 1420 + 0x4a C++
00000040()
ntdll.dll!7c949d18()
mcsTunnel.exe!std::char_traits<char>::compare(const char *
_First1=0x00e1eefc, const char * _First2=0x00457cb6, unsigned int _Count=0)
Line 348 + 0x10 C++

::compare(unsigned int _Off=1953653093, unsigned int _N0=1952540002, const

char * _Ptr=0xcccccc00, unsigned int _Count=12) Line 1423 + 0x10 C++
4873634d()
mcsTunnel.exe!XmlRpc::XmlRpcServerConnection::writeResponse() Line 179 +
0xd C++
mcsTunnel.exe!XmlRpc::XmlRpcServerConnection::handleEvent(unsigned int
__formal=1) Line 60 + 0x8 C++
mcsTunnel.exe!XmlRpc::XmlRpcDispatch::work(double
timeout=-1.0000000000000000) Line 129 + 0x15 C++
mcsTunnel.exe!XmlRpc::XmlRpcServer::work(double
msTime=-1.0000000000000000) Line 128 C++
mcsTunnel.exe!mcsTunnelSvc::mcsTunnelMain() Line 2490 C++
mcsTunnel.exe!mcsTunnelThread(void * param=0x0012fe58) Line 2422 C++
kernel32.dll!7c80b50b()
kernel32.dll!7c8399f3()

The strings being compared are always the same two strings, although we do
not make an explicit comparison for these in our code. The applicaton is an
open source XML RPC library that we're using to interface a Java app with a
C++ "tunnel" to access system level services (instead of using JNI). We have
a heartbeat the fires periodically so the Java app and the tunnel can keep
tabs on each other's status. When the exception occurs, the string being
compared is always the name of the heartbeat method that the Java
application calls in the tunnel. The XML RPC library has various logging
levels and we typically run it at minimum logging. I tried setting it to
maximum logging to see if it would help in identifying the source of the
problem and when I did that the exception no longer occurred, or at least it
did not in any of my testing, and normally the exception occurs within a
minute or so.

So we're stumped. It could very well be a bug somewhere in the XML RPC
library code, although outside of the debugger the library appears to work
flawlessly.

 

[Oleg Starodumov]

ntdll.dll!7c901230()
ntdll.dll!7c96c943()
ntdll.dll!7c949eb9()

There is no symbols for system DLLs on your machine,
but these functions actually are:
ntdll.dll!DbgBreakPoint
ntdll.dll!RtlpBreakPointHeap
ntdll.dll!RtlAllocateHeapSlowly

First, try to get good symbols. You can configure VS.NET to download them from
the symbol server, as described here:
http://support.microsoft.com/default.aspx?scid=kb;en-us;319037

With the proper symbols, it is possible that the call stack will be different,
closer to the real problem.

Next, these three functions on the call stack usually mean that the heap
has been corrupted. If you look at Debug Output window, it is probable
that there is a message that describes the problem.

Also you can enable PageHeap to catch the problem.
If you have downloaded Debugging Tools (as described in the KB above), run
gflags -p /enable YourApp.exe /full
(gflags.exe is located in the installation directory of Debugging Tools)

Then rebuild your application with release version of CRT library
(debug CRT can hide some bugs from PageHeap) and run the application
under debugger (I mean VS.NET debugger).
Problems found by PageHeap will be reported via access violations
or hardcoded breakpoints; if you see one, check the call stack to see
where the problem is.

If the measures described above do not help, look also for a race condition.

Regards,
Oleg