Unable to find the cause of showing MEMORY_CORRUPTION_LARGE and ACCESS_VIOLATION whereas the callstack show clr!DontCallDirectlyForceStackOverflow - clr

My customer is facing random crashes. And got multiple dumps from him but Unable to analyze the reason correctly. Crashes are on Windows Server 2008 and 2012.
he customer is running an application on a windows network:
Most users access to the application from their local clients (all Windows 10).
Some users are running the application via terminal servers (TS1 and TS2).
TS1 is a Windows Server 2008 R2.
TS2 is a Windows Server 2012 R2.
On TS1, TS2 and all Windows 10 PCs Actian PSQL Clients are installed (13.30.037.000).
A Windows Server 2012 R2 is used as a file and database server (Actian PSQL 13.31.006.000).
Windbg shows :
*** procdump -e -ma 7824 C:\Debugging
*** Unhandled exception: C0000005.ACCESS_VIOLATION'
!analyze -v shows :
GetUrlPageData2 (WinHttp) failed: 12002.
FAULTING_IP:
clr!DontCallDirectlyForceStackOverflow+12
74184c2a 0000 add byte ptr [eax],al
EXCEPTION_RECORD: 76ef042f -- (.exr 0x76ef042f)
ExceptionAddress: 0be13000
ExceptionCode: 0be03000
ExceptionFlags: 0be0b000
NumberParameters: 199442432
Parameter[0]: 0bef4000
Parameter[1]: 0bf09000
Parameter[2]: 0bf0c000
Parameter[3]: 0bf0f000
Parameter[4]: 0bf2d000
Parameter[5]: 0bf41000
Parameter[6]: 0bf46000
Parameter[7]: 0bf55000
Parameter[8]: 0bf5a000
Parameter[9]: 0bf62000
Parameter[10]: 0bf67000
Parameter[11]: 0bf82000
Parameter[12]: 0bfc3000
Parameter[13]: 0bfc7000
Parameter[14]: 0bfdf000
CONTEXT: 0b971530 -- (.cxr 0xb971530;r)
eax=000001ff ebx=01ffffff ecx=ffff0000 edx=00000000 esi=00000000 edi=0000003f
eip=003fffff esp=00000000 ebp=00000000 iopl=0 vip vif nv up di pl nz na po nc
cs=0000 ss=0000 ds=0000 es=0000 fs=ffff gs=0000 efl=ffff0000
0000:ffff ?? ???
Last set context:
eax=000001ff ebx=01ffffff ecx=ffff0000 edx=00000000 esi=00000000 edi=0000003f
eip=003fffff esp=00000000 ebp=00000000 iopl=0 vip vif nv up di pl nz na po nc
cs=0000 ss=0000 ds=0000 es=0000 fs=ffff gs=0000 efl=ffff0000
0000:ffff ?? ???
Resetting default scope
DEFAULT_BUCKET_ID: CODE_CORRUPTION
PROCESS_NAME: MgxpaRuntime.exe
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_PARAMETER1: 00000001
EXCEPTION_PARAMETER2: 0b9703bc
WRITE_ADDRESS: 0b9703bc
FOLLOWUP_IP:
clr!DontCallDirectlyForceStackOverflow+12
74184c2a 0000 add byte ptr [eax],al
APPLICATION_VERIFIER_FLAGS: 6aeef141
WARNING: !chkimg output was truncated to 50 lines. Invoke !chkimg without '-lo [num_lines]' to view entire output.
17666 errors : !clr (73cb1000-7440c927)
APP: mgxparuntime.exe
ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) x86fre
MANAGED_STACK: !dumpstack -EE
Failed to load data access DLL, 0x80004005
Some functionality may be impaired
OS Thread Id: 0x3d58 (9)
TEB information is not available so a stack size of 0xFFFF is assumed
Current frame:
ChildEBP RetAddr Caller, Callee
PRIMARY_PROBLEM_CLASS: CODE_CORRUPTION
BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS
LAST_CONTROL_TRANSFER: from 73fcb5b4 to 74184c2a
STACK_TEXT:
0b9713c0 73fcb5b4 92ca4142 0b971450 73db0690 clr!DontCallDirectlyForceStackOverflow+0x12
0b9713e8 73db062a 92ca469e 00b06970 00000000 clr!CLRVectoredExceptionHandler+0x9b
0b971434 76eb6822 0b971450 0b971580 0b971530 clr!CLRVectoredExceptionHandlerShim+0xd6
0b971484 76f1cfc1 00000000 0b971a78 091351a0 ntdll!RtlpCallVectoredHandlers+0xba
0b971514 0b9719e8 76ef042f 0b971530 0b971580 ntdll!RtlDispatchException+0x72
WARNING: Frame IP not in any known module. Following frames may be wrong.
0b971520 0b971580 0b971530 0b971580 c0000005 0xb9719e8
0b971530 00000000 00000000 74184c2a 00000002 0xb971580
STACK_COMMAND: ~9s; .ecxr ; kb
MODULE_NAME: memory_corruption
IMAGE_NAME: memory_corruption
FOLLOWUP_NAME: memory_corruption
DEBUG_FLR_IMAGE_TIMESTAMP: 0
MEMORY_CORRUPTOR: LARGE
BUCKET_ID: MEMORY_CORRUPTION_LARGE
FAILURE_BUCKET_ID: CODE_CORRUPTION_c0000005_memory_corruption!Unknown
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:code_corruption_c0000005_memory_corruption!unknown
FAILURE_ID_HASH: {52b16108-a3a5-b115-868e-9fc9ce8e1ee0}
Followup: memory_corruption
---------
Can someone help to understand the cause of such crashes? If i try to check such dumps in DebugDiag , it shows the recursive call stack ...But what is the actual cause?

Related

Address Sanitizer Warning

For a few days now I get the following issue when starting up the Address Sanitizer within Xcode 7.3. The error messages printed to the Xcode console when the Sanitizer found an issue (that was actually suppressed by a file):
==13392==WARNING: Can't write to symbolizer at fd 55
==13392==WARNING: Can't write to symbolizer at fd 55
==13392==WARNING: Can't write to symbolizer at fd 55
==13392==WARNING: Can't write to symbolizer at fd 55
==13392==WARNING: Failed to use and restart external symbolizer!
I found the error messages in the repository but still I can't explain what's going on. Obviously the internal write function fails but I have no idea whats causing this. Any ideas?
https://github.com/Microsoft/compiler-rt/blob/master/lib/sanitizer_common/sanitizer_symbolizer_process_libcdep.cc#L100
ASAN is missing from your path. The following was done outside Xcode to see if I could manifest the error and it was easy if the path was undefined. My guess is XCode cannot find it where it's looking or as in the following case the ASAN path is undefined.
When you try this if you add and remove it from your path the error goes away but the line numbers also disappear ie if you want to see the actual error message again you need to use
unset ASAN_SYMBOLIZER_PATH
not
ASAN_SYMBOLIZER_PATH=
Create a c program as follows...
int main(void){
int a[3];
a[3] = 4;
return 0;
}
Compile it, please ignore warnings for now...
gcc -std=c11 -Wall -g3 -fno-omit-frame-pointer -fsanitize=address broken_asan_test.c
./a.out
You should see something like this...
=================================================================
==29192==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff5ad1052c at pc 0x000104eefe78 bp 0x7fff5ad104f0 sp 0x7fff5ad104e8
WRITE of size 4 at 0x7fff5ad1052c thread T0
#0 0x104eefe77 in atos[29193]: [fatal] 'pid_for_task' failed: (os/kern) failure (5) (+0x100000e77)
==29192==WARNING: Can't write to symbolizer at fd 3
#1 0x7fff940495ac in atos[29206]: [fatal] 'pid_for_task' failed: (os/kern) failure (5) (+0x35ac)
#2 0x0 (<unknown module>)
Notice this line
==29192==WARNING: Can't write to symbolizer at fd 3
Change to have the symbolizer added to your path...
export ASAN_SYMBOLIZER_PATH=/usr/local/Cellar/llvm/3.6.2/bin/llvm-symbolizer
and the error disappears...
=================================================================
==29312==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff55ac450c at pc 0x00010a13be78 bp 0x7fff55ac44d0 sp 0x7fff55ac44c8
WRITE of size 4 at 0x7fff55ac450c thread T0
#0 0x10a13be77 in main (/git/ghub/doc/c/./a.out+0x100000e77)
#1 0x7fff940495ac in start (/usr/lib/system/libdyld.dylib+0x35ac)
#2 0x0 (<unknown module>)

Lost some debug functionality in Delphi 2007

Recently I have lost some of my debug functionality in Delphi 2007.
Specifically, the Watch List Window is completely disable as are all but a
few of the Watch List's popup menu items. The only menu items that are
enabled are
Add Group...
Show Column Headers
Stay on Top
Dockable
This is the case in the ide and the program running or not running
Breakpoints work as does tooltip expressions at breakpoint.
In Tools | Options , Code completion, Error Insight, Block Completion and
Code Template Completion are unchecked, all other options are checked.
In Tools | Options, Debugger Options are set Integrated Debugging and
Automatically close files implicitly...' checked , all others unchecked.
In Project | Options (Compiler), Optimization unchecked All Debugging
section items checked with exception of 'definitions only'
Conditional Defines are DEBUG;madExcept
When a breakpoint is hit, the Watch List windows shows 'Evaluating...' for
each Watch Name. BTW, the watch names were entered some time ago when all
debugging features were working.
After a period of attempted debugging while at a breakpoint (stopped), the
Run button on toolbar becomes disabled and I have to click 'Run | Program
Reset' on the menu at which time madExcept
throws the following exception from the IDE:
date/time : 2014-09-28, 09:08:17, 855ms
computer name : JOHNTAYLOR-LAP
user name : JT <admin>
registered owner : Microsoft / Microsoft
operating system : Windows 7 x64 build 7600
system language : English
system up time : 10 days 22 hours
program up time : 3 days
processors : 8x Intel(R) Core(TM) i7 CPU Q 840 # 1.87GHz
physical memory : 7944/16308 MB (free/total)
free disk space : (C:) 83.99 GB
display mode : 1024x768, 32 bit
process id : $2994
allocated memory : 354.77 MB
command line : "C:\CodeGear RAD Studio\CodeGear\RAD Studio\5.0\bin\bds.exe" -np
executable : bds.exe
current module : madExcept_.bpl
exec. date/time : 2007-12-11 15:04
version : 11.0.2902.10471
compiled with : Delphi 2006/07
madExcept version : 4.0.6
callstack crc : $f8d6ff12, $83616f26, $cd9b05a3
exception number : 1
exception class : EListError
exception message : List index out of bounds (0).
main thread ($325c):
20032558 +03c rtl100.bpl Classes 3525 +3 TInterfaceList.Put
2087a8f4 +008 dbkdebugide100.bpl Debug 6414 +1 TThread.RemoveNotifier
20aa3b13 +043 coreide100.bpl WatchWin 1543 +1 TWatchWindow.EvaluteComplete
20878cf9 +0fd dbkdebugide100.bpl Debug 5564 +12 TThread.EvalComplete
20877660 +02c dbkdebugide100.bpl Debug 4871 +2 TDbkApiEvent.Send
208784c8 +024 dbkdebugide100.bpl Debug 5300 +2 TDebugKernel.apiComplete
2013a81a +012 vcl100.bpl Controls 4039 +1 TControl.ScreenToClient
209b6b21 +065 coreide100.bpl EditorControl 6744 +3 TCustomEditControl.WMNCHitTest
7759e74d +078 ntdll.dll RtlAnsiStringToUnicodeString
76977b0a +016 USER32.dll CallWindowProcA
20885499 +039 dbkdebugide100.bpl Debug 11455 +3 TDebugger.DBKWndProc
20040e4c +014 rtl100.bpl Classes 11583 +8 StdWndProc
7696810d +00a USER32.dll DispatchMessageA
Can anyone help me get this straightened out ? This started suddenly about
a month ago and not pursuant to any new component installation that I am
aware of.
I had the same problem in BDS2006. And I found a very simple solution that worked for me. Open your project desktop-file (.dsk). Go to the watches section. I just removed some unwanted watches (don't forget to adjust the count), started Delphi again and my watches and menu-items were enabled.

uboot environment variable save doesn't seem to work

I'm having problems trying to save environment variables in uBoot and have them persist across reboots, see trace below. This is with U-Boot 2009.08-00000-g19b0e8d-dirty (May 29 2012 - 16:09:40). Any ideas as to what could be wrong? Is the "Writing to Flash... Flash not Erased" message significant?
-> setenv ipaddr 10.1.10.28
-> saveenv
Saving Environment to Flash...
. done
Un-Protected 1 sectors
. done
Un-Protected 1 sectors
Erasing Flash...
. done
Erased 1 sectors
Writing to Flash... Flash not Erased
. done
Protected 1 sectors
. done
Protected 1 sectors
-> printenv
bootdelay=1
baudrate=115200
serverip=10.1.10.40
loadaddr=41000000
u-boot=q4/u-boot.bin
load=tftp ${loadaddr) ${u-boot}
upd=run load; run prog
bootargs=console=ttyMCF2,115200 panic=10
rootpath=/tftpboot/ltib
nfsargs=setenv bootargs ${bootargs} root=/dev/nfs rw nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off
nfs=run nfsargs; tftp q4/uImage-nfs; bootm
prog=prot off 0 3ffff;era 0 3ffff;cp.b ${loadaddr} 0 ${filesize};save
ext_wp_off=mw.b 10010020 e0 1
ethact=FEC0
ethaddr=3c:98:bf:00:00:14
eth1addr=3c:98:bf:00:00:15
nfsaddr=10.1.10.40
httpPort=81
hostname=
stdin=serial
stdout=serial
stderr=serial
mem=65024k
ipaddr=10.1.10.28
Environment size: 686/32763 bytes
-> reset
U-Boot 2009.08-00000-g19b0e8d-dirty (May 29 2012 - 16:09:40)
(c) 2012.
CPU: Freescale MCF53013 (Mask:73 Version:1)
CPU CLK 240 MHz BUS CLK 80 MHz
Board: RevB
I2C: ready
DRAM: 64 MB
FLASH: 32 MB
In: serial
Out: serial
Err: serial
Net: FEC0, FEC1
-> printenv
bootdelay=1
baudrate=115200
serverip=10.1.10.40
loadaddr=41000000
u-boot=q4/u-boot.bin
load=tftp ${loadaddr) ${u-boot}
upd=run load; run prog
bootargs=console=ttyMCF2,115200 panic=10
rootpath=/tftpboot/ltib
nfsargs=setenv bootargs ${bootargs} root=/dev/nfs rw nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off
nfs=run nfsargs; tftp q4/uImage-nfs; bootm
prog=prot off 0 3ffff;era 0 3ffff;cp.b ${loadaddr} 0 ${filesize};save
ext_wp_off=mw.b 10010020 e0 1
ethact=FEC0
ethaddr=3c:98:bf:00:00:14
eth1addr=3c:98:bf:00:00:15
nfsaddr=10.1.10.40
httpPort=81
hostname=
stdin=serial
stdout=serial
stderr=serial
mem=65024k
Environment size: 668/32763 bytes
->
flinfo output is:
-> flinfo
Bank # 1: CFI conformant FLASH (16 x 16) Size: 32 MB in 262 Sectors
AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E
Erase timeout: 8192 ms, write timeout: 1 ms
Buffer write timeout: 5 ms, buffer size: 64 bytes
Sector Start Addresses:
00000000 RO 00008000 RO 00010000 RO 00018000 RO 00020000 RO
00040000 00060000 00080000 000A0000 000C0000
000E0000 00100000 00120000 00140000 00160000
00180000 001A0000 001C0000 001E0000 00200000
00220000 00240000 00260000 00280000 002A0000
002C0000 002E0000 00300000 00320000 00340000
00360000 00380000 003A0000 003C0000 003E0000
00400000 00420000 00440000 00460000 00480000
004A0000 004C0000 004E0000 00500000 00520000
00540000 00560000 00580000 005A0000 005C0000
005E0000 00600000 00620000 00640000 00660000
00680000 006A0000 006C0000 006E0000 00700000
00720000 00740000 00760000 00780000 007A0000
007C0000 007E0000 00800000 00820000 00840000
00860000 00880000 008A0000 008C0000 008E0000
00900000 00920000 00940000 00960000 00980000
009A0000 009C0000 009E0000 00A00000 00A20000
00A40000 00A60000 00A80000 00AA0000 00AC0000
00AE0000 00B00000 00B20000 00B40000 00B60000
00B80000 00BA0000 00BC0000 00BE0000 00C00000
00C20000 00C40000 00C60000 00C80000 00CA0000
00CC0000 00CE0000 00D00000 00D20000 00D40000
00D60000 00D80000 00DA0000 00DC0000 00DE0000
00E00000 00E20000 00E40000 00E60000 00E80000
00EA0000 00EC0000 00EE0000 00F00000 00F20000
00F40000 00F60000 00F80000 00FA0000 00FC0000
00FE0000 01000000 01020000 01040000 01060000
01080000 010A0000 010C0000 010E0000 01100000
01120000 01140000 01160000 01180000 011A0000
011C0000 011E0000 01200000 01220000 01240000
01260000 01280000 012A0000 012C0000 012E0000
01300000 01320000 01340000 01360000 01380000
013A0000 013C0000 013E0000 01400000 01420000
01440000 01460000 01480000 014A0000 014C0000
014E0000 01500000 01520000 01540000 01560000
01580000 015A0000 015C0000 015E0000 01600000
01620000 01640000 01660000 01680000 016A0000
016C0000 016E0000 01700000 01720000 01740000
01760000 01780000 017A0000 017C0000 017E0000
01800000 01820000 01840000 01860000 01880000
018A0000 018C0000 018E0000 01900000 01920000
01940000 01960000 01980000 019A0000 019C0000
019E0000 01A00000 01A20000 01A40000 01A60000
01A80000 01AA0000 01AC0000 01AE0000 01B00000
01B20000 01B40000 01B60000 01B80000 01BA0000
01BC0000 01BE0000 01C00000 01C20000 01C40000
01C60000 01C80000 01CA0000 01CC0000 01CE0000
01D00000 01D20000 01D40000 01D60000 01D80000
01DA0000 01DC0000 01DE0000 01E00000 01E20000
01E40000 01E60000 01E80000 01EA0000 01EC0000
01EE0000 01F00000 01F20000 01F40000 01F60000
01F80000 01FA0000 01FC0000 01FE0000 RO 01FE8000 RO
01FF0000 01FF8000
I had a similar issue after using "fw_setenv" to update my U-Boot environment.
What I found is that my U-Boot was unable to unlock the environment sector after fw_setenv locked it from Linux. Everything would look ok, but then the write would fail the same way yours did.
I was able to fix my problem by unlocking the env sector from Linux using flash_unlock.
This occurs after using fw_setenv on occasion in Linux. If you can boot into your running Linux, the execute "mtd unlock /devX" where X is your partition in which your u-boot environment variables live, then boot back into u-boot. You should be able to execute a "Saveenv"
I reflashed my Flash and can now save environment variables OK. Must have been some corruption?

unevictable page

I getting a kernel crash as below. Here I can observe large memory is present in unevictablle page.
I wish to know when exactly memory is added to unevictable page list.
Also, from the below message I can understand only 1724kB is available in the system.
is it correct?
kswapd0: page allocation failure. order:0, mode:0xd0
[<c002aed4>] (unwind_backtrace+0x0/0xdc) from [<c006d5b0>] (__alloc_pages_nodemask+0x490/0x4ec)
[<c006d5b0>] (__alloc_pages_nodemask+0x490/0x4ec) from [<c008416c>] (cache_alloc_refill+0x260/0x4f4)
[<c008416c>] (cache_alloc_refill+0x260/0x4f4) from [<c0084498>] (__kmalloc+0x98/0xd8)
[<c0084498>] (__kmalloc+0x98/0xd8) from [<c01f73d8>] (__alloc_skb+0x44/0x124)
[<c01f73d8>] (__alloc_skb+0x44/0x124) from [<c01f7cac>] (skb_copy+0x2c/0xa0)
Exception stack(0xc4ecbdf0 to 0xc4ecbe38)
bde0: 00000000 00000064 c0347718 00000000
be00: 00000001 00000000 c0347718 c0347718 c4ecbf54 00000000 00000000 000000fd
be20: c4ecbf00 c4ecbe38 c00724b4 c00724c4 80000013 ffffffff
[<c0024b18>] (__irq_svc+0x38/0xc0) from [<c00724c4>] (shrink_zone+0x88/0x70c)
[<c00724c4>] (shrink_zone+0x88/0x70c) from [<c0072ff4>] (kswapd+0x34c/0x4d8)
[<c0072ff4>] (kswapd+0x34c/0x4d8) from [<c004dcec>] (kthread+0x7c/0x84)
[<c004dcec>] (kthread+0x7c/0x84) from [<c0025ed0>] (kernel_thread_exit+0x0/0x8)
Mem-info:
Normal per-cpu:
CPU 0: hi: 42, btch: 7 usd: 36
Active_anon:124 active_file:0 inactive_anon:129
inactive_file:0 unevictable:8111 dirty:0 writeback:0 unstable:0
free:431 slab:19526 mapped:408 pagetables:53 bounce:0
Normal free:1724kB min:1396kB low:1744kB high:2092kB active_anon:496kB inactive_anon:516kB active_file:0kB inactive_file:0kB unevictable:32444kB present:121920kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 103*4kB 34*8kB 3*16kB 3*32kB 2*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 1724kB
8114 total pagecache pages
30720 pages of RAM
547 free pages
1204 reserved pages
19526 slab pages
1662 pages shared
0 pages swap cached
Unevictable pages are simply pages that can't be paged out for a variety of reasons. It might mean that the page belongs to a ramdisk, was protected by a call to mlock(), shared and locked, or any other circumstances where the kernel was told 'don't touch'. This is managed by the kernel's LRU framework.
Can you provide some more context into the crash?

Vista 64 bit BSOD when running a Delphi 2009 Application

I have an application that I have converted to Delphi 2009 I have "String format checking" On and the standard memory manager. I downloaded the MS debugging tools at http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx and got some debug files but I am not sure what to make of them. I would like some pointers on where to go from here. Below is the top part of the debug file (bottom has all the drivers loaded);
Opened log file 'c:\debuglog.txt'
1: kd> .sympath srv*c:\symbols*http://msdl.microsoft.com/downloads/symbols
Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/downloads/symbols
Expanded Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/downloads/symbols
1: kd> .reload;!analyze -v;r;kv;lmnt;.logclose;q
Loading Kernel Symbols
...............................................................
................................................................
.........................
Loading User Symbols
Loading unloaded module list
........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050033
Arg3: 00000000000006f8
Arg4: fffff80001ee1678
Debugging Details:
------------------
BUGCHECK_STR: 0x7f_8
CUSTOMER_CRASH_COUNT: 4
DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT
PROCESS_NAME: SomeApplication.e
CURRENT_IRQL: 1
EXCEPTION_RECORD: fffffa60087b43c8 -- (.exr 0xfffffa60087b43c8)
.exr 0xfffffa60087b43c8
ExceptionAddress: fffff80001ed0150 (nt!RtlVirtualUnwind+0x0000000000000250)
ExceptionCode: 10000004
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 00000000000000d8
TRAP_FRAME: fffffa60087b4470 -- (.trap 0xfffffa60087b4470)
.trap 0xfffffa60087b4470
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000050 rbx=0000000000000000 rcx=0000000000000004
rdx=00000000000000d8 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80001ed0150 rsp=fffffa60087b4600 rbp=fffffa60087b4840
r8=0000000000000006 r9=fffff80001e4e000 r10=ffffffffffffff88
r11=fffff8000204c000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!RtlVirtualUnwind+0x250:
fffff800`01ed0150 488b02 mov rax,qword ptr [rdx] ds:00000000`000000d8=????????????????
.trap
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80001ea81ee to fffff80001ea8450
STACK_TEXT:
fffffa60`005f1a68 fffff800`01ea81ee : 00000000`0000007f 00000000`00000008 00000000`80050033 00000000`000006f8 : nt!KeBugCheckEx
fffffa60`005f1a70 fffff800`01ea6a38 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x6e
fffffa60`005f1bb0 fffff800`01ee1678 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb8
fffffa60`087b3c90 fffff800`01ea82a9 : fffffa60`087b43c8 00000000`00000001 fffffa60`087b4470 00000000`0000023b : nt!KiDispatchException+0x34
fffffa60`087b4290 fffff800`01ea70a5 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000001 : nt!KiExceptionDispatch+0xa9
fffffa60`087b4470 fffff800`01ed0150 : fffffa60`087b5498 fffffa60`087b4e70 fffff800`01f95190 fffff800`01e4e000 : nt!KiPageFault+0x1e5
fffffa60`087b4600 fffff800`01ed3f78 : fffffa60`00000001 00000000`00000000 00000000`00000000 ffffffff`ffffff88 : nt!RtlVirtualUnwind+0x250
fffffa60`087b4670 fffff800`01ee1706 : fffffa60`087b5498 fffffa60`087b4e70 fffffa60`00000000 00000000`00000000 : nt!RtlDispatchException+0x118
fffffa60`087b4d60 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchException+0xc2
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KiDoubleFaultAbort+b8
fffff800`01ea6a38 90 nop
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiDoubleFaultAbort+b8
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 49e0237f
FAILURE_BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b8
BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b8
Followup: MachineOwner
---------
rax=fffffa60005f1b70 rbx=fffffa60087b43c8 rcx=000000000000007f
rdx=0000000000000008 rsi=fffffa60087b4470 rdi=fffff80001f9bfa4
rip=fffff80001ea8450 rsp=fffffa60005f1a68 rbp=fffffa60005f1c30
r8=0000000080050033 r9=00000000000006f8 r10=fffff80001ee1678
r11=fffffa60087b4468 r12=0000000000000000 r13=fffffa60087b4290
r14=fffff8000205149c r15=fffff80001e4e000
iopl=0 nv up ei ng nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000282
nt!KeBugCheckEx:
fffff800`01ea8450 48894c2408 mov qword ptr [rsp+8],rcx ss:0018:fffffa60`005f1a70=000000000000007f
Child-SP RetAddr : Args to Child : Call Site
fffffa60`005f1a68 fffff800`01ea81ee : 00000000`0000007f 00000000`00000008 00000000`80050033 00000000`000006f8 : nt!KeBugCheckEx
fffffa60`005f1a70 fffff800`01ea6a38 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x6e
fffffa60`005f1bb0 fffff800`01ee1678 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb8 (TrapFrame # fffffa60`005f1bb0)
fffffa60`087b3c90 fffff800`01ea82a9 : fffffa60`087b43c8 00000000`00000001 fffffa60`087b4470 00000000`0000023b : nt!KiDispatchException+0x34
fffffa60`087b4290 fffff800`01ea70a5 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000001 : nt!KiExceptionDispatch+0xa9
fffffa60`087b4470 fffff800`01ed0150 : fffffa60`087b5498 fffffa60`087b4e70 fffff800`01f95190 fffff800`01e4e000 : nt!KiPageFault+0x1e5 (TrapFrame # fffffa60`087b4470)
fffffa60`087b4600 fffff800`01ed3f78 : fffffa60`00000001 00000000`00000000 00000000`00000000 ffffffff`ffffff88 : nt!RtlVirtualUnwind+0x250
fffffa60`087b4670 fffff800`01ee1706 : fffffa60`087b5498 fffffa60`087b4e70 fffffa60`00000000 00000000`00000000 : nt!RtlDispatchException+0x118
fffffa60`087b4d60 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchException+0xc2
The help file for windbg goes into some more detail on the various kernel mode bug checks, and what to do about them. I don't really know your level of expertise or what you are expecting here, but generally speaking nothing you can do in a user mode program such as delphi will ever cause a bug check. Therefore we would normally go with the assumption of a driver bug, or some kind of hardware failure.
I entered UNEXPECTED_KERNEL_MODE_TRAP into the help index and got this page:
Windows Driver Kit: Debugging Tools
Bug Check 0x7F:
UNEXPECTED_KERNEL_MODE_TRAP The
UNEXPECTED_KERNEL_MODE_TRAP bug check
has a value of 0x0000007F. This bug
check indicates that the Intel CPU
generated a trap and the kernel failed
to catch this trap.
This trap could be a bound trap (a
trap the kernel is not permitted to
catch) or a double fault (a fault that
occurred while processing an earlier
fault, which always results in a
system failure).
elided...
0x00000008, or Double Fault, indicates
that an exception occurs during a call
to the handler for a prior exception.
Typically, the two exceptions are
handled serially. However, there are
several exceptions that cannot be
handled serially, and in this
situation the processor signals a
double fault. There are two common
causes of a double fault:
A kernel
stack overflow. This overflow occurs
when a guard page is hit, and the
kernel tries to push a trap frame.
Because there is no stack left, a
stack overflow results, causing the
double fault. If you think this
overview has occurred, use !thread to
determine the stack limits, and then
use kb (Display Stack Backtrace) with
a large parameter (for example, kb
100) to display the full stack.
A
hardware problem.
Cause Bug check 0x7F typically occurs
after you install a faulty or
mismatched hardware (especially
memory) or if installed hardware
fails.
A double fault can occur when the
kernel stack overflows. This overflow
occurs if multiple drivers are
attached to the same stack. For
example, if two file system filter
drivers are attached to the same stack
and then the file system recurses back
in, the stack overflows.
elided...
It goes on into a lot more detail about that, and the various debugging techniques and what you can do to troubleshoot the problem.

Resources