WinXP Server Error on 100Gb VM process: "Application requested termination in unusual way"...?
Ira Baxter
that is computationally and storage intense. It uses somewhere north
of 100GB of Virtual Memory; we've configured the VM space to
be some 280GB, much larger than we actually reach.
The machine is a 8 processor system with 16Gb of physical RAM.
As far as we can tell, the application actually works; at least, it
runs on all the test cases we give it, including under the debugger,
without any errors, up until it encounters a need for some 100GB.
Windows then stops the application with the error message in the subject
line
(or something pretty close to that). We believe that this error
message can occur on invalid memory references, and likely on
any hardware trap. But we can't see any actual fault in the code,
and there isn't any more detail about the cause of the error
to give us a clue what might be happening.
Any folks out there with some hints about the problem,
or how to find the cause of the error?
Anybody with actual experience on this large a VM?
--
Ira Baxter, CTO
www.semanticdesigns.com
Kerem Gümrükcü
"Ira Baxter" <idba...@semdesigns.com> schrieb im Newsbeitrag
news:OcM8MEy%23HHA...@TK2MSFTNGP03.phx.gbl...
Hi Ira,
the Error Message means that some routine or some segment
of executable code requested this error. If your handwritten
code did not throw this exception, then some runtime loaded
from your application could have thrown this error. In your
case you should run the application inside a debugger, configure
the debugger to break into that exception and have a look at
things like the call-stack and loaded modules to see, where
the exception araised. Then you will have (i hope) more information
about the exact reason of the exception.
Try to run the application under the Debugging Tools from
Microsoft if you want:
http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx
Important would be a backtrack of the call-stack and the memory
to see where the exception has been thrown. Do you know whether
your application loads any debug runtimes or debug build code? Try
to find the address of the crash and as much as possible information
you can get. Use Process Monitor to see what your app is doing and
to get the most recent call stack when it terminates. Process Monitor
is a great app in this case,...see the stack tab on the process property
window,...
Regards
Kerem
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
ker...@pro-it-education.de
Latest Open-Source Project: http://sourceforge.net/projects/checkdiskshell
Thats me at work: http://www.pro-it-education.de/staff/keremg/
Pro-IT Education http://www.pro-it-education.de/
Professional IT-Training and Consulting
-----------------------
"This reply is provided as is, without warranty express or implied."
Chris Becke
runtime is asked to handle an assert.
I am not too sure *why* the VC RT authors chose to handle calls to the
_assert() function in this way, but they did. There might be other runtime
calls that display this message (perhaps _pure() for example).
Linking to the debug, rather than release c/cpp runtime, might make the
problem easier to resolve.
"Ira Baxter" <idba...@semdesigns.com> wrote in message
news:OcM8MEy%23HHA...@TK2MSFTNGP03.phx.gbl...
Jochen Kalmbach [MVP]
> Any folks out there with some hints about the problem,
> or how to find the cause of the error?
> Anybody with actual experience on this large a VM?
You should write a minidump if an unhandled exception occurs.
Normal "DrWatsnon" (or WER) writes a minidump...
Then you should be able to see the course of this problem...
Greetings
Jochen
Michael Mehlich
When the error occurred, windows allowed us to attach to the
VisualStudio2005(sp1) debugger. However, as soon as this was done,
the process was terminated without any other useful information
being provided by the debugger. In particular, we did not get
any call stack.
Running the debug version is not really an option either as this
takes literally forever and requires significantly more memory.
We ran the application in debug mode on smaller examples without
any problems, though.
I also checked whether there is any debug build code included
but couldn't find any. The application consists of a single
translation unit and, as far as I can tell, only includes
non-debug libraries provided by VisualStudio/windows.
I'll give the process monitor a try and see whether I can get
some more information...
Thanks,
Michael
Michael Mehlich
We tried the debug version on smaller problem sizes without any problems.
Unfortunately, the debug version takes extremely long to run
(even on smaller problem sizes) and requires a huge amount of
extra memory. So, I don't think this is really an option to run
on the large problem size we really want to solve.
Or is there a way to configure VisualStudio2005(sp1) to perform
selective checking only and, especially, to use less memory overhead
when debugging?
For what it's worth. By sharing some cached information in the
application, we were able to reduce the memory demands somewhat.
The result is now running significantly past the point where it
crashed before... It hasn't yet reached the magic 100+GByte, though...
--
Michael
Kerem Gümrükcü
"Michael Mehlich" <mmeh...@semanticdesigns.com> schrieb im Newsbeitrag
news:OfEoRXG$HHA....@TK2MSFTNGP04.phx.gbl...
Hi Michael,
you should give the process Monitor a try, since you
can see the callstack in the history of the applications
execution. It would be also great when you will have a
memory dump of your application, at least a dump that
can show you frames and callstack, so that you can assign
the Address of the call stack to the memory dump and
vice versa,...
Regards
Kerem
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
ker...@pro-it-education.de
Best Quote: "Ain't nobody a badass with a double dose
of rock salt...", Kill Bill Vol.2