Re: Need help with "Fatal Execution Engine Error"

Thanks for your input John.

Anyways: They're should be no reason why an allocation should fail. Largest
free region is close 8 TB (64-bit OS and process), and there's close to 1 GB
of virtual memory free on my computer when the error occurs (so there's no
reason why a failure to commit memory should occur).

/Erik

"John Lan" wrote:

it looks like debugbreak occured in mscorwks!SVR::gc_heap::handle_oom(),
possiblly gc can't allocate a new large enough segment to meet alloc
request.
!address -summary can print MAX possible consective vm region, e.g...

0:000> !address -summary

-------------------- Usage SUMMARY --------------------------
TotSize ( KB) Pct(Tots) Pct(Busy) Usage
419b000 ( 67180) : 03.20% 28.58% : RegionUsageIsVAD
71a62000 ( 1862024) : 88.79% 00.00% : RegionUsageFree
410b000 ( 66604) : 03.18% 28.33% : RegionUsageImage
2100000 ( 33792) : 01.61% 14.38% : RegionUsageStack
21000 ( 132) : 00.01% 00.06% : RegionUsageTeb
41c4000 ( 67344) : 03.21% 28.65% : RegionUsageHeap
0 ( 0) : 00.00% 00.00% : RegionUsagePageHeap
1000 ( 4) : 00.00% 00.00% : RegionUsagePeb
1000 ( 4) : 00.00% 00.00% : RegionUsageProcessParametrs
1000 ( 4) : 00.00% 00.00% : RegionUsageEnvironmentBlock
Tot: 7fff0000 (2097088 KB) Busy: 0e58e000 (235064 KB)

-------------------- Type SUMMARY --------------------------
TotSize ( KB) Pct(Tots) Usage
71a62000 ( 1862024) : 88.79% : <free>
410b000 ( 66604) : 03.18% : MEM_IMAGE
24f0000 ( 37824) : 01.80% : MEM_MAPPED
7f93000 ( 130636) : 06.23% : MEM_PRIVATE

-------------------- State SUMMARY --------------------------
TotSize ( KB) Pct(Tots) Usage
8f75000 ( 146900) : 07.00% : MEM_COMMIT
71a62000 ( 1862024) : 88.79% : MEM_FREE
5619000 ( 88164) : 04.20% : MEM_RESERVE

Largest free region: Base 23c3e000 - Size 1eed2000 (506696 KB)

mscorwks!SVR::GCHeap::Alloc() has size parameter push on stack, you can dump
it to evaluate.
too many large objects?

"erik at Starcounter" <erikatStarcounter@xxxxxxxxxxxxxxxxxxxxxxxxx> 写入消息
news:16FC94A5-044E-4C61-9CCB-00D2298FA9C9@xxxxxxxxxxxxxxxx

Thank you GP, you're absolutely right, I had the wrong symbols. Very
stupid
of m too assume I had.

We'll, I'm pretty sure I have the right symbols now (symchk says their the
right ones at least) and here's the real stack trace:

00000000`084b92d8 00000000`76db2f8b ntdll!ZwTerminateProcess+0xa
00000000`084b92e0 000007fe`f161a46f ntdll!RtlExitUserProcess+0x8b
00000000`084b9310 000007fe`f1c02f35 mscorwks!SafeExitProcess+0xc7
00000000`084b9590 000007fe`f164aa81
mscorwks!EEPolicy::HandleFatalError+0x75
00000000`084b95e0 000007fe`f1682c30
mscorwks!CLRVectoredExceptionHandlerPhase3+0xcd
00000000`084b9620 000007fe`f1682e37
mscorwks!CLRVectoredExceptionHandlerPhase2+0x30
00000000`084b9690 000007fe`f164a6e6
mscorwks!CLRVectoredExceptionHandler+0xff
00000000`084b9710 00000000`76dceb7c
mscorwks!CLRVectoredExceptionHandlerShim+0x42
00000000`084b9750 00000000`76dce8a5 ntdll!RtlpCallVectoredHandlers+0xac
00000000`084b97c0 00000000`76dd59f8 ntdll!RtlDispatchException+0x25
00000000`084b9e60 000007fe`f16f1138 ntdll!KiUserExceptionDispatcher+0x2e
00000000`084ba400 000007fe`f16f1801
mscorwks!SVR::gc_heap::try_allocate_more_space+0x448
00000000`084ba4f0 000007fe`f16f1a82 mscorwks!SVR::GCHeap::Alloc+0xd1
00000000`084ba530 000007fe`f16f66c7 mscorwks!AllocateObject+0xb2
00000000`084ba5b0 000007fe`f1ba031a mscorwks!MethodTable::FastBox+0x23
00000000`084ba5f0 000007ff`01d45ed7 mscorwks!JIT_Box+0x13a
--> Managed code.

The debug break was in the following place:

00000000084b8e08 000007fef1a232ba ntdll!DbgBreakPoint
00000000084b8e10 000007fef1c02f2e mscorwks!`string'+0x8953a
00000000084b9590 000007fef164aa81 mscorwks!EEPolicy::HandleFatalError+0x6e
...

Still have no idea what it could be of course but obviously, something
goes
wrong when allocating memory. Running the server GC in this case but I had
the error when using the workstation GC as well.

Thanks for you help GP.

/Erik

"GP" wrote:

Hello!

When listing the stack in WinDbg I get the following output:

0000000`085f9428 00000000`770f2f8b ntdll!NtTerminateProcess+0xa
00000000`085f9430 000007fe`f210a46f ntdll!RtlExitUserProcess+0x8b
00000000`085f9460 000007fe`f26f2f35 mscorwks+0xea46f
00000000`085f96e0 000007fe`f213aa81 mscorwks!PreBindAssembly+0x99a75
00000000`085f9730 000007fe`f2172c30 mscorwks!GetCLRFunction+0x1126d
00000000`085f9770 000007fe`f2172e37
mscorwks!CreateApplicationContext+0x2ecd4 00000000`085f97e0
000007fe`f213a6e6 mscorwks!CreateApplicationContext+0x2eedb
00000000`085f9860 00000000`7710eb7c mscorwks!GetCLRFunction+0x10ed2
...

You're missing the symbols for mscorwks (mscorwks!GetCLRFunction would be
very very big in size (+0x99a75)). Use !symfix <localsymbolpath> and
.reload
to see the "right" call-stack.


GP




.

Relevant Pages

  • Re: Freeing memory - will it be available immediately
    ... Your interpretation of "as the standard defines it" is ... Your interpretation of "for further allocation" as "for futher ... Except that this ignores the very reason for the standard, ... return the memory back to the OS in the manner you describe. ...
    (comp.lang.c)
  • Re: Memory leak with CAsyncSocket::Create
    ... read my essay on how storage allocators work. ... Create method is consuming system memory that is not released back to ... The memory consumption is either shown as "Mem Usage" on the Task ... many levels of allocation going ...
    (microsoft.public.vc.mfc)
  • Re: Can I Increase size of nNoMansLandSize?
    ... look at memory, I see that in the "no man's land" that the debug memory ... allocation creates, one of the DWORDs has been changed to 0x0000001. ... I can't find any rhyme or reason to when this happens, ... I can't find any other way to tap into the new/debug scheme. ...
    (microsoft.public.vc.mfc)
  • Re: OT: XP TaskManager - Physical memory vs PageFile?
    ... Yet Physical Memory says I've got 143,742k ... Is PF usage unconditionally an undesirable thing? ... allocation rather than PF usage. ... Many apps ask the OS to allocate ...
    (alt.comp.periphs.mainboard.asus)
  • Re: memory allocation/deallocation problem
    ... > seems to be going through the deallocation loop just fine. ... > interesting thing I just noticed is that if the memory requirements ... It is this huge 1.5 Gb chunk that for some reason ... to just the allocation and deallocation code? ...
    (comp.lang.c)