|
|
|
date: Wed, 19 Sep 2007 19:56:14 -0500,
group: microsoft.public.platformsdk.win_base_svcs
back
WinXP Server Error on 100Gb VM process: "Application requested termination in unusual way"...?
We have an Visual Studio 2005 C++ X64 single-threaded application
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
date: Wed, 19 Sep 2007 19:56:14 -0500
author: Ira Baxter
Re: WinXP Server Error on 100Gb VM process: "Application requested termination in unusual way"...?
"Ira Baxter" schrieb im Newsbeitrag
news:OcM8MEy%23HHA.4880@TK2MSFTNGP03.phx.gbl...
> We have an Visual Studio 2005 C++ X64 single-threaded application
> 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
>
>
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ü
kerem.g@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."
date: Thu, 20 Sep 2007 04:27:44 +0200
author: Kerem G?mr?kc?
Re: WinXP Server Error on 100Gb VM process: "Application requested termination in unusual way"...?
This error message typically occurs when the release version of the VC
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" wrote in message
news:OcM8MEy%23HHA.4880@TK2MSFTNGP03.phx.gbl...
> We have an Visual Studio 2005 C++ X64 single-threaded application
> 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
>
>
date: Thu, 20 Sep 2007 10:01:59 +0200
author: Chris Becke
Re: WinXP Server Error on 100Gb VM process: "Application requested
termination in unusual way"...?
Kerem Gümrükcü wrote:
> "Ira Baxter" schrieb im Newsbeitrag
> news:OcM8MEy%23HHA.4880@TK2MSFTNGP03.phx.gbl...
>> We have an Visual Studio 2005 C++ X64 single-threaded application
>> 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
>>
>>
>
> 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
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
date: Fri, 21 Sep 2007 10:41:02 -0500
author: Michael Mehlich
Re: WinXP Server Error on 100Gb VM process: "Application requested
termination in unusual way"...?
Why would there be any _assert() call in a non-debug version?
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
Chris Becke wrote:
> This error message typically occurs when the release version of the VC
> 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" wrote in message
> news:OcM8MEy%23HHA.4880@TK2MSFTNGP03.phx.gbl...
>> We have an Visual Studio 2005 C++ X64 single-threaded application
>> 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
>>
>>
>
>
date: Fri, 21 Sep 2007 10:49:44 -0500
author: Michael Mehlich
Re: WinXP Server Error on 100Gb VM process: "Application requested termination in unusual way"...?
"Michael Mehlich" schrieb im Newsbeitrag
news:OfEoRXG$HHA.4828@TK2MSFTNGP04.phx.gbl...
> Kerem Gümrükcü wrote:
>> "Ira Baxter" schrieb im Newsbeitrag
>> news:OcM8MEy%23HHA.4880@TK2MSFTNGP03.phx.gbl...
>>> We have an Visual Studio 2005 C++ X64 single-threaded application
>>> 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
>>>
>>>
>>
>> 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
>
> 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
>
>
>
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ü
kerem.g@pro-it-education.de
Best Quote: "Ain't nobody a badass with a double dose
of rock salt...", Kill Bill Vol.2
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."
date: Fri, 21 Sep 2007 18:38:25 +0200
author: Kerem G?mr?kc?
|
|
