So I have a print server running Windows Server 2008 64 bit. It server up crystal reports to a variety of printers, some old, some new. That means there's a few different drivers on there. Recently we started having issues where the splWOW64 process will hang and all printing will back up. If we kill that process the queue prints normally. Looking at the what appears to be the hung print job every time we can see what printer and what report were printing, however it's never the same report or printer. We have full dumps of the splwow64 process and were told that the HP universal print driver PCL5 was causing the issue. It had been working for most of our printers for years before with no problems. So we removed that driving and started using individual drivers for each model of printer, all PCL6 if we could find them on the microsoft driver database. None of this has worked to fix the issue. It still happens 2-3 times a day depending on how busy it is. I've never used windbg to debug anything, I have below the results of !analyze -v -hang for a recent dump. It's gibberish to me at the moment. Maybe someone out there can see something obviously wrong?
FAULTING_IP:
+0
00000000`00000000 ?? ???
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000000000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0
CONTEXT: 0000000000000000 -- (.cxr 0x0;r)
rax=0000000000000000 rbx=0000000000000000 rcx=00000000004486f8
rdx=00000000ffffffff rsi=00000000ffffffff rdi=0000000000000088
rip=0000000076d812fa rsp=000000000028f708 rbp=0000000000000001
r8=000000000028f7d8 r9=0000000000000001 r10=0000000000000000
r11=0000000000000202 r12=0000000000000000 r13=00000000ff963440
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!NtWaitForSingleObject+0xa:
00000000`76d812fa c3 ret
FAULTING_THREAD: 0000000000000000
BUGCHECK_STR: HANG
DEFAULT_BUCKET_ID: APPLICATION_HANG
PROCESS_NAME: splwow64.exe
ERROR_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>
EXCEPTION_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
APP: splwow64.exe
ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre
DERIVED_WAIT_CHAIN:
Dl Eid Cid WaitType
-- --- ------- --------------------------
0 b68.19bc Unknown
WAIT_CHAIN_COMMAND: ~0s;k;;
BLOCKING_THREAD: 00000000000019bc
PRIMARY_PROBLEM_CLASS: APPLICATION_HANG
LAST_CONTROL_TRANSFER: from 000007fefcfa10dc to 0000000076d812fa
STACK_TEXT:
00000000`0028f708 000007fe`fcfa10dc : 00000000`0044d000 00000000`00400000 00000000`0044cff0 00000000`76d840fd : ntdll!NtWaitForSingleObject+0xa
00000000`0028f710 000007fe`fd2ed95d : 00000000`004485f0 00000000`0000000a 00000000`00000000 00000000`00000088 : KERNELBASE!WaitForSingleObjectEx+0x79
00000000`0028f7b0 000007fe`fd36f42c : 00000000`00000000 00000000`00000000 00000000`004485f0 000007fe`fd2ff74e : rpcrt4!EVENT::Wait+0xd
00000000`0028f7e0 000007fe`fd33a879 : 00000000`004485f0 00000000`004485f0 00000000`00000000 00000000`00000001 : rpcrt4!RPC_SERVER::WaitForStopServerListening+0x1c
00000000`0028f810 000007fe`fd2ffa49 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000001 : rpcrt4!Invoke+0x13e46
00000000`0028f850 00000000`ff966b98 : 00000000`00000000 00000000`0000000a 00000000`0000000a 00000000`000004d2 : rpcrt4!RpcServerListen+0x49
00000000`0028f880 00000000`ff9671f1 : 00000000`00000000 00000000`0028fa20 00000000`00187c90 00000000`00003000 : splwow64!TLoad64BitDllsMgr::StartLdrRPCServer+0x19c
00000000`0028f9d0 00000000`ff967fb2 : 00000000`00187c90 00000000`00003000 00000000`00001a20 00000000`00003000 : splwow64!TLoad64BitDllsMgr::Run+0x4d
00000000`0028fa10 00000000`ff96d095 : 00000000`00000000 00000000`00000000 00000000`00187d20 00000000`00000000 : splwow64!wmain+0x1ae
00000000`0028fa50 00000000`76b2652d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : splwow64!ConvertStringSecurityDescriptorToSecurityDescriptorW+0x19b
00000000`0028fa90 00000000`76d5c541 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`0028fac0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d
FOLLOWUP_IP:
splwow64!TLoad64BitDllsMgr::StartLdrRPCServer+19c
00000000`ff966b98 8bd8 mov ebx,eax
SYMBOL_STACK_INDEX: 6
SYMBOL_NAME: splwow64!TLoad64BitDllsMgr::StartLdrRPCServer+19c
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: splwow64
IMAGE_NAME: splwow64.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4f35fbfe
STACK_COMMAND: ~0s ; kb
BUCKET_ID: X64_HANG_splwow64!TLoad64BitDllsMgr::StartLdrRPCServer+19c
FAILURE_BUCKET_ID: APPLICATION_HANG_cfffffff_splwow64.exe!TLoad64BitDllsMgr::StartLdrRPCServer
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:application_hang_cfffffff_splwow64.exe!tload64bitdllsmgr::startldrrpcserver
FAILURE_ID_HASH: {369fae16-3854-e2c0-c756-fdab044a0958}
Followup: MachineOwner
You should make a kernel dump ( see: http://support.microsoft.com/kb/244139 )
Then you should do:
search your process !process 0 0 splwow64
switch to the found process
.process /p addr
list all thread for found process !process addr 17
find your thread
find ALPC handle in the stack and find a kernel object: !handle handle
print ALPC port object !alpc ob_addr
find a print corresponding server port
If you have done these step you must know a RPC server process which is hang your RPC request
Related
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?
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?
I've just stumbled across this and I'm a bit puzzled.
I have an out-of-the-box VS 2010 F# project, with all default settings, targeting .NET 4.0.
The F# code is like this:
let test(a:int, b:int, c:int) = min a (min b c)
When I compile it for release, the generated IL contains some strange NOP
instructions scattered around. Like this:
The generated IL for this (with all default settings):
.method public static int32 test(int32 a,
int32 b,
int32 c) cil managed
{
// Code size 20 (0x14)
.maxstack 4
.locals init ([0] int32 V_0)
// HERE
IL_0000: nop
IL_0001: ldarg.1
IL_0002: ldarg.2
IL_0003: bge.s IL_0009
IL_0005: ldarg.1
// HERE
IL_0006: nop
IL_0007: br.s IL_000b
IL_0009: ldarg.2
// HERE
IL_000a: nop
IL_000b: stloc.0
IL_000c: ldarg.0
IL_000d: ldloc.0
IL_000e: bge.s IL_0012
IL_0010: ldarg.0
IL_0011: ret
IL_0012: ldloc.0
IL_0013: ret
} // end of method Module1::test
My .fsproj project configuration is:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<Tailcalls>true</Tailcalls>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<WarningLevel>3</WarningLevel>
<DocumentationFile>bin\Release\TestFsIL.XML</DocumentationFile>
</PropertyGroup>
Now, if I comment out line <DebugType>pdbonly</DebugType>, the NOP instructions
disappear. But of course so does the PDB file!
.method public static int32 test(int32 a,
int32 b,
int32 c) cil managed
{
// Code size 17 (0x11)
.maxstack 4
.locals init (int32 V_0)
IL_0000: ldarg.1
IL_0001: ldarg.2
IL_0002: bge.s IL_0007
IL_0004: ldarg.1
IL_0005: br.s IL_0008
IL_0007: ldarg.2
IL_0008: stloc.0
IL_0009: ldarg.0
IL_000a: ldloc.0
IL_000b: bge.s IL_000f
IL_000d: ldarg.0
IL_000e: ret
IL_000f: ldloc.0
IL_0010: ret
} // end of method Module1::test
There is also a subtle different in the .locals line:
.locals init ([0] int32 V_0)
vs
.locals init (int32 V_0)
When I tried C# compiler, it generates NOP instructions only in the
debug builds, but these seem to go away in release builds, even when
PDB files are included using <DebugType>pdbonly</DebugType>.
Questions:
Why are NOP instructions generated in F# in release build when PDB files are included, when C# seems to be able to avoid this.
Is there any way to get rid of those NOP, but still have the PDB files?
PS. There are related questions on SO here
and here,
but all the answers there say
you are compiling in debug mode, if you compile in release mode, the NOP goes away
which contradicts my experience with F# compiler as demonstrated.
I don't exactly know how this works internally in the F# compiler (somebody from the F# team may have a better answer), but my guess is that generating nop instructions is just a fairly easy way to generate locations that can be referred to from the pdb file.
The pdb file needs to specify some IL range for expression in the code where you can place a breakpoint - and this is the case in both Debug and Release mode. This means that if you place a breakpoint somewhere, there needs to be a corresponding location in the IL. However, if there is no actual instruction, corresponding to the source code location, the compiler needs to insert something - so it adds nop.
In Release mode, the F# compiler does more optimizations, but if you want pdb files, it still needs to provide location for all source code locations. This might not be needed in C#, because C# maps more closely to the source IL, but it might be harder to avoid this in F#.
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?
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.