We have setup procdump as the (AeDebug) postmortem debugger to capture dumps of unhandled exceptions. The registry key is set to "c:\my\sysinternals\procdump.exe" -accepteula -ma -j "c:\dumps" %ld %ld %p
Currently I'm looking at a dump where the process that triggered a crash dump is still running hours after dumping the process has completed?!
It was my assumption that any process that triggers a crash dump is about to get terminated?
From WinDbg
Debug session time: Tue Dec 1 01:53:06.000 2015 (UTC + 1:00)
System Uptime: 18 days 18:09:24.556
Process Uptime: 1 days 0:09:31.000
0:000> ~
. 0 Id: 178c.eb4 Suspend: 0 Teb: fffdd000 Unfrozen
...
0:000> ? 178c
Evaluate expression: 6028 = 0000178c
From ProcExp
Looking at PID 6028 on Tue Dec 1 10:00:00, hours after the dump from 01:53:06.000
<3thParty>.exe:6028 Properties
Started: 1:43:35 30/11/2015
Edit
0:000> ~*kb1000
. 0 Id: 178c.eb4 Suspend: 0 Teb: fffdd000 Unfrozen
# ChildEBP RetAddr Args to Child
00 0018de38 77cd8567 00000574 00000001 00000000 ntdll!ZwWaitForSingleObject+0x15
01 0018debc 77cd8695 0018e0c8 0018e118 00000001 ntdll!RtlReportExceptionEx+0x14b
02 0018df14 772f8dd8 0018e0c8 0018e118 00000001 ntdll!RtlReportException+0x86
03 0018df34 772f8edb 0018dfa4 0018dfa4 00000000 ole32!SilentlyReportExceptions+0x79
04 0018df48 772f94e5 0018dfa4 00000000 00000000 ole32!ServerExceptionFilter+0xbb
05 0018df60 77360827 0018dfa4 0148502c 01048240 ole32!AppInvokeExceptionFilterWithMethodAddress+0x11
06 0018df7c 77183f21 00000000 0018faf8 77278760 ole32!SyncStubInvoke+0x82
07 0018df90 77183eae 00000000 00000000 00000000 msvcrt!_EH4_CallFilterFunc+0x12
08 0018dfbc 77286771 7736662c 7726ea10 0018e0c8 msvcrt!_except_handler4_common+0x8e
09 0018dfdc 77c8b499 0018e0c8 0018fae8 0018e118 ole32!_except_handler4+0x20
0a 0018e000 77c8b46b 0018e0c8 0018fae8 0018e118 ntdll!ExecuteHandler2+0x26
0b 0018e024 77c8b40e 0018e0c8 0018fae8 0018e118 ntdll!ExecuteHandler+0x24
0c 0018e0b0 77c40133 0118e0c8 0018e118 0018e0c8 ntdll!RtlDispatchException+0x127
0d 0018e0b0 00404880 0118e0c8 0018e118 0018e0c8 ntdll!KiUserExceptionDispatcher+0xf
WARNING: Stack unwind information not available. Following frames may be wrong.
0e 0018f61c 75a15932 01485018 01549420 00000000 <3thParty>+0x4880
0f 0018f640 75a905f1 00523859 0018f828 00000004 rpcrt4!Invoke+0x2a
10 0018fa44 7735aec1 010ac688 0101fb58 0104ea78 rpcrt4!NdrStubCall2+0x2ea
11 0018fa8c 76acffd3 010ac688 0104ea78 0101fb58 ole32!CStdStubBuffer_Invoke+0x3c
12 0018fab0 7735d876 010ac688 0104ea78 0101fb58 oleaut32!CUnivStubWrapper::Invoke+0xcb
13 0018faf8 7735ddd0 0104ea78 01048240 01095448 ole32!SyncStubInvoke+0x3c
14 0018fb44 77278a43 0104ea78 010be578 01097470 ole32!StubInvoke+0xb9
15 0018fc20 77278938 0101fb58 00000000 01097470 ole32!CCtxComChnl::ContextInvoke+0xfa
16 0018fc3c 7727950a 0104ea78 00000001 01097470 ole32!MTAInvoke+0x1a
17 0018fc68 7735dccd 0104ea78 00000001 01097470 ole32!STAInvoke+0x46
18 0018fc9c 7735db41 d0908070 0101fb58 01097470 ole32!AppInvoke+0xab
19 0018fd7c 7735e1fd 0104ea20 0101fef0 00000400 ole32!ComInvokeWithLockAndIPID+0x372
1a 0018fda4 77279367 0104ea20 00000400 00ff3548 ole32!ComInvoke+0xc5
1b 0018fdb8 77279326 0104ea20 00000000 77279286 ole32!ThreadDispatch+0x23
1c 0018fdfc 76eb62fa 00e2019e 00000400 0000babe ole32!ThreadWndProc+0x161
1d 0018fe28 76eb6d3a 77279286 00e2019e 00000400 user32!InternalCallWinProc+0x23
1e 0018fea0 76eb77c4 00000000 77279286 00e2019e user32!UserCallWinProcCheckWow+0x109
1f 0018ff00 76eb788a 77279286 00000000 00e2019e user32!DispatchMessageWorker+0x3bc
20 0018ff10 004aea6a 0018ff34 00010001 0018ff70 user32!DispatchMessageW+0xf
21 0018ff2c 004aeaaf 00e2019e 00000400 0000babe <3thParty>+0xaea6a
22 0018ff50 00a0c705 0018ff78 00a0c733 0018ff70 <3thParty>+0xaeaaf
23 0018ff70 00a3024b 0018ffc4 00404cac 0018ff88 <3thParty>!FrobWidget+0x4db279
24 0018ff88 7766338a fffde000 0018ffd4 77c69f72 <3thParty>!FrobWidget+0x4fedbf
25 0018ff94 77c69f72 fffde000 2ca36a95 00000000 kernel32!BaseThreadInitThunk+0xe
26 0018ffd4 77c69f45 00a30220 fffde000 ffffffff ntdll!__RtlUserThreadStart+0x70
27 0018ffec 00000000 00a30220 fffde000 00000000 ntdll!_RtlUserThreadStart+0x1b
1 Id: 178c.17a4 Suspend: 0 Teb: fffda000 Unfrozen
# ChildEBP RetAddr Args to Child
00 023cfed4 76b614ab 00000180 00000000 00000000 ntdll!ZwWaitForSingleObject+0x15
01 023cff40 77661194 00000180 ffffffff 00000000 KERNELBASE!WaitForSingleObjectEx+0x98
02 023cff58 77661148 00000180 ffffffff 00000000 kernel32!WaitForSingleObjectExImplementation+0x75
03 023cff6c 76bb511d 00000180 ffffffff 00000000 kernel32!WaitForSingleObject+0x12
04 023cff88 7766338a 00234b88 023cffd4 77c69f72 ws2_32!SockAsyncThread+0x25
05 023cff94 77c69f72 00234b88 2e876a95 00000000 kernel32!BaseThreadInitThunk+0xe
06 023cffd4 77c69f45 76bb50f8 00234b88 ffffffff ntdll!__RtlUserThreadStart+0x70
07 023cffec 00000000 76bb50f8 00234b88 00000000 ntdll!_RtlUserThreadStart+0x1b
2 Id: 178c.1108 Suspend: 0 Teb: fffd7000 Unfrozen
# ChildEBP RetAddr Args to Child
00 0273fdf4 77c82f91 00000003 010169d0 00000001 ntdll!NtWaitForMultipleObjects+0x15
01 0273ff88 7766338a 00000000 0273ffd4 77c69f72 ntdll!TppWaiterpThread+0x33d
02 0273ff94 77c69f72 010169a0 2ec86a95 00000000 kernel32!BaseThreadInitThunk+0xe
03 0273ffd4 77c69f45 77c82e65 010169a0 ffffffff ntdll!__RtlUserThreadStart+0x70
04 0273ffec 00000000 77c82e65 010169a0 00000000 ntdll!_RtlUserThreadStart+0x1b
3 Id: 178c.1794 Suspend: 0 Teb: fffac000 Unfrozen
# ChildEBP RetAddr Args to Child
00 0908fe28 77c83392 000001c0 0908fedc 25b36ac9 ntdll!NtWaitForWorkViaWorkerFactory+0x12
01 0908ff88 7766338a 01015748 0908ffd4 77c69f72 ntdll!TppWorkerThread+0x216
02 0908ff94 77c69f72 01015748 25b36a95 00000000 kernel32!BaseThreadInitThunk+0xe
03 0908ffd4 77c69f45 77c83e85 01015748 ffffffff ntdll!__RtlUserThreadStart+0x70
04 0908ffec 00000000 77c83e85 01015748 00000000 ntdll!_RtlUserThreadStart+0x1b
4 Id: 178c.5e4 Suspend: 0 Teb: fffaf000 Unfrozen
# ChildEBP RetAddr Args to Child
00 08b0fe28 77c83392 000001c4 08b0fedc 240b6ac9 ntdll!NtWaitForWorkViaWorkerFactory+0x12
01 08b0ff88 7766338a 01015748 08b0ffd4 77c69f72 ntdll!TppWorkerThread+0x216
02 08b0ff94 77c69f72 01015748 240b6a95 00000000 kernel32!BaseThreadInitThunk+0xe
03 08b0ffd4 77c69f45 77c83e85 01015748 ffffffff ntdll!__RtlUserThreadStart+0x70
04 08b0ffec 00000000 77c83e85 01015748 00000000 ntdll!_RtlUserThreadStart+0x1b
5 Id: 178c.c80 Suspend: 0 Teb: fffa9000 Unfrozen
# ChildEBP RetAddr Args to Child
00 0b03fed8 76b63bd5 00000000 0b03ff1c 57962de4 ntdll!ZwDelayExecution+0x15
01 0b03ff40 76b644a5 0000ea60 00000000 0b03ff78 KERNELBASE!SleepEx+0x65
02 0b03ff50 7724d98d 0000ea60 010bd460 7724cd48 KERNELBASE!Sleep+0xf
03 0b03ff5c 7724cd48 00000000 00000000 010bd460 ole32!CROIDTable::WorkerThreadLoop+0x14
04 0b03ff78 7724d87a 00000000 00000000 0b03ff94 ole32!CRpcThread::WorkerLoop+0x26
05 0b03ff88 7766338a 010bd460 0b03ffd4 77c69f72 ole32!CRpcThreadCache::RpcWorkerThreadEntry+0x16
06 0b03ff94 77c69f72 010bd460 27b86a95 00000000 kernel32!BaseThreadInitThunk+0xe
07 0b03ffd4 77c69f45 7724d864 010bd460 ffffffff ntdll!__RtlUserThreadStart+0x70
08 0b03ffec 00000000 7724d864 010bd460 00000000 ntdll!_RtlUserThreadStart+0x1b
6 Id: 178c.14f4 Suspend: 0 Teb: fffa6000 Unfrozen
# ChildEBP RetAddr Args to Child
00 0b13fe28 77c83392 000001bc 0b13fedc 27a86ac9 ntdll!NtWaitForWorkViaWorkerFactory+0x12
01 0b13ff88 7766338a 01015748 0b13ffd4 77c69f72 ntdll!TppWorkerThread+0x216
02 0b13ff94 77c69f72 01015748 27a86a95 00000000 kernel32!BaseThreadInitThunk+0xe
03 0b13ffd4 77c69f45 77c83e85 01015748 ffffffff ntdll!__RtlUserThreadStart+0x70
04 0b13ffec 00000000 77c83e85 01015748 00000000 ntdll!_RtlUserThreadStart+0x1b
7 Id: 178c.ee4 Suspend: 0 Teb: fffa3000 Unfrozen
# ChildEBP RetAddr Args to Child
00 0b23fcbc 76b614ab 00000578 00000000 0b23fd04 ntdll!ZwWaitForSingleObject+0x15
01 0b23fd28 77661194 00000578 00002710 00000000 KERNELBASE!WaitForSingleObjectEx+0x98
02 0b23fd40 77661148 00000578 00002710 00000000 kernel32!WaitForSingleObjectExImplementation+0x75
03 0b23fd54 6e22b3d6 00000578 00002710 00000000 kernel32!WaitForSingleObject+0x12
04 0b23ff88 7766338a 01072188 0b23ffd4 77c69f72 comsvcs!PingThread+0x131
05 0b23ff94 77c69f72 01072188 27986a95 00000000 kernel32!BaseThreadInitThunk+0xe
06 0b23ffd4 77c69f45 6e22b320 01072188 ffffffff ntdll!__RtlUserThreadStart+0x70
07 0b23ffec 00000000 6e22b320 01072188 00000000 ntdll!_RtlUserThreadStart+0x1b
8 Id: 178c.914 Suspend: 0 Teb: fff9d000 Unfrozen
# ChildEBP RetAddr Args to Child
00 0d26ff5c 72be635c 00000534 0d26ff90 0d26ff84 ntdll!ZwRemoveIoCompletion+0x15
01 0d26ff88 7766338a 72be64b3 0d26ffd4 77c69f72 mswsock!SockAsyncThread+0x83
02 0d26ff94 77c69f72 0101d3e8 219d6a95 00000000 kernel32!BaseThreadInitThunk+0xe
03 0d26ffd4 77c69f45 72be62ee 0101d3e8 ffffffff ntdll!__RtlUserThreadStart+0x70
04 0d26ffec 00000000 72be62ee 0101d3e8 00000000 ntdll!_RtlUserThreadStart+0x1b
Edit 2
0:000> .exr -1
ExceptionAddress: 00404880 (<3thParty>+0x00004880)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000000
Attempt to read from address 00000000
0:000> ~* e s -d esp L0xffff 0x1003f
0018e118 0001003f 00000000 00000000 00000000 ?...............
0018e9a8 0001003f 00000000 00000000 00000000 ?...............
0018efa8 0001003f 00000000 00000000 00000000 ?...............
0:000> .cxr 0018e118
eax=00fc2c80 ebx=00000000 ecx=00000000 edx=00fc2c50 esi=00000000 edi=00000000
eip=00404880 esp=0018e400 ebp=0018f61c iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
<3thParty>+0x4880:
00404880 8b11 mov edx,dword ptr [ecx] ds:002b:00000000=????????
0:000> kbnf
*** Stack trace for last set context - .thread/.cxr resets it
# Memory ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
00 0018f61c 75a15932 01485018 01549420 00000000 <3thParty>+0x4880
01 24 0018f640 75a905f1 00523859 0018f828 00000004 rpcrt4!Invoke+0x2a
02 404 0018fa44 7735aec1 010ac688 0101fb58 0104ea78 rpcrt4!NdrStubCall2+0x2ea
03 48 0018fa8c 76acffd3 010ac688 0104ea78 0101fb58 ole32!CStdStubBuffer_Invoke+0x3c
04 24 0018fab0 7735d876 010ac688 0104ea78 0101fb58 oleaut32!CUnivStubWrapper::Invoke+0xcb
05 48 0018faf8 7735ddd0 0104ea78 01048240 01095448 ole32!SyncStubInvoke+0x3c
06 4c 0018fb44 77278a43 0104ea78 010be578 01097470 ole32!StubInvoke+0xb9
07 dc 0018fc20 77278938 0101fb58 00000000 01097470 ole32!CCtxComChnl::ContextInvoke+0xfa
08 1c 0018fc3c 7727950a 0104ea78 00000001 01097470 ole32!MTAInvoke+0x1a
09 2c 0018fc68 7735dccd 0104ea78 00000001 01097470 ole32!STAInvoke+0x46
0a 34 0018fc9c 7735db41 d0908070 0101fb58 01097470 ole32!AppInvoke+0xab
0b e0 0018fd7c 7735e1fd 0104ea20 0101fef0 00000400 ole32!ComInvokeWithLockAndIPID+0x372
0c 28 0018fda4 77279367 0104ea20 00000400 00ff3548 ole32!ComInvoke+0xc5
0d 14 0018fdb8 77279326 0104ea20 00000000 77279286 ole32!ThreadDispatch+0x23
0e 44 0018fdfc 76eb62fa 00e2019e 00000400 0000babe ole32!ThreadWndProc+0x161
0f 2c 0018fe28 76eb6d3a 77279286 00e2019e 00000400 user32!InternalCallWinProc+0x23
10 78 0018fea0 76eb77c4 00000000 77279286 00e2019e user32!UserCallWinProcCheckWow+0x109
11 60 0018ff00 76eb788a 77279286 00000000 00e2019e user32!DispatchMessageWorker+0x3bc
12 10 0018ff10 004aea6a 0018ff34 00010001 0018ff70 user32!DispatchMessageW+0xf
13 1c 0018ff2c 004aeaaf 00e2019e 00000400 0000babe <3thParty>+0xaea6a
14 24 0018ff50 00a0c705 0018ff78 00a0c733 0018ff70 <3thParty>+0xaeaaf
15 20 0018ff70 00a3024b 0018ffc4 00404cac 0018ff88 <3thParty>!FrobWidget+0x4db279
16 18 0018ff88 7766338a fffde000 0018ffd4 77c69f72 <3thParty>!FrobWidget+0x4fedbf
17 c 0018ff94 77c69f72 fffde000 2ca36a95 00000000 kernel32!BaseThreadInitThunk+0xe
18 40 0018ffd4 77c69f45 00a30220 fffde000 ffffffff ntdll!__RtlUserThreadStart+0x70
19 18 0018ffec 00000000 00a30220 fffde000 00000000 ntdll!_RtlUserThreadStart+0x1b
Normally, an unhandled exception does cause the process to be terminated once the dump has been captured. What's happening here is that you are running afoul of a compatibility behavior: If a COM server crashes while handling an inbound request, COM historically "handles" the crash by abandoning the call, returning RPC_E_SERVERFAULT to the external caller, and then pretending that the crash never occurred.
That's why the process is still running after the crash dump is taken: The exception was handled. Mind you, it was "handled" by ignoring it, but technically it was handled.
I would recommend using IGlobalOptions to set the COMGLB_EXECPTION_HANDLING property to one of the COMGLB_EXCEPTION_DONOT_HANDLE... values.
Related
I am trying to start an Oracle 11g database but it is failing with ORA-01092 and ORA-00600 errors:
Microsoft Windows [Version 6.0.6001]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Users\Administrator>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Wed Sep 11 15:21:30 2019
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup upgrade
ORACLE instance started.
Total System Global Area 430075904 bytes
Fixed Size 2176448 bytes
Variable Size 356518464 bytes
Database Buffers 67108864 bytes
Redo Buffers 4272128 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [],
[], [], [], []
Process ID: 5044
Session ID: 1 Serial number: 5
SQL> conn
Enter user-name: delhipilot
Enter password:
ERROR:
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Process ID: 0
Session ID: 0 Serial number: 0
SQL>
How can I start my database properly?
Here is an example of patching the system rollback segment header to avoid errors ORA-600 [4193] and ORA-600 [4194] during startup. Note that in this example the segment header is located in file 1 block 9 and the example in note 452620.1 is using file 1 block 2 as the segment header.
parnassusdata can also provide the recovery service.
It is a partial block dump for system rbs segment header file 1 block 9:
TRN CTL:: seq: 0x003a chd: 0x0017 ctl: 0x0052 inc: 0x00000000 nfb: 0x0001
mgc: 0x8002 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x00400197.003a.02 scn: 0x0000.004fbbf0
Version: 0x01
FREE BLOCK POOL::
uba: 0x00400197.003a.02 ext: 0x4 spc: 0x1dd2
uba: 0x00000000.0037.05 ext: 0x1 spc: 0x1d6c
uba: 0x00000000.0035.37 ext: 0x5 spc: 0x538
uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0
1. Generate the bbed executable:
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk `pwd`/bbed
mv bbed $ORACLE_HOME/bin
2. Create file file.lis with the datafile where the system rollback segment header is stored:
file.lis has:
<relative file#> <datafile name> <size in bytes: v$datafile.bytes>
In our session file.lis contains:
1 /oradata/s102/system01.dbf 524288000
3. Create file bbed.par
bbed.par has:
MODE=EDIT
LISTFILE=<File name created in step2>
BLOCKSIZE=<db_block_size>
In our session bbed.par contains
MODE=EDIT
LISTFILE=file.lis
BLOCKSIZE=8192
4. Run bbed. Use password blockedit:
$ bbed parfile=bbed.par
Password:
BBED: Release 2.0.0.0.0 - Limited Production on Thu Sep 27 10:06:25 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
************* !!! For Oracle Internal Use only !!! ***************
BBED>
5. Go to Block where the system rollback segment header is stored. In our example it is block 9:
BBED> set block 9
BLOCK# 9
6. Run map to see the C structures for the block and the DBA:
BBED> map
File: /oradata/s102/system01.dbf (1)
Block: 9 Dba:0x00400009
------------------------------------------------------------
Unlimited Undo Segment Header
struct kcbh, 20 bytes #0
struct ktech, 72 bytes #20
struct ktemh, 16 bytes #92
struct ktetb[6], 48 bytes #108
struct ktuxc, 104 bytes #4148
struct ktuxe[255], 10200 bytes #4252
ub4 tailchk #8188
Note that dba=0x00400009 is file 1 block 9, so we are positioned in the correct block.
7. Print the structure ktuxc:
BBED> print ktuxc
struct ktuxc, 104 bytes #4148
struct ktuxcscn, 8 bytes #4148
ub4 kscnbas #4148 0x004fbbf1
ub2 kscnwrp #4152 0x0000
struct ktuxcuba, 8 bytes #4156
ub4 kubadba #4156 0x00400197
ub2 kubaseq #4160 0x003a
ub1 kubarec #4162 0x03
sb2 ktuxcflg #4164 1 (KTUXCFSK)
ub2 ktuxcseq #4166 0x003a
sb2 ktuxcnfb #4168 1
ub4 ktuxcinc #4172 0x00000000
sb2 ktuxcchd #4176 6
sb2 ktuxcctl #4178 23
ub2 ktuxcmgc #4180 0x8002
ub4 ktuxcopt #4188 0x7ffffffe
struct ktuxcfbp[0], 12 bytes #4192
struct ktufbuba, 8 bytes #4192
ub4 kubadba #4192 0x00400197
ub2 kubaseq #4196 0x003a
ub1 kubarec #4198 0x0c
sb2 ktufbext #4200 4
sb2 ktufbspc #4202 5630
8. Modify ktuxc.ktuxcnfb to 0x0000
BBED> set offset ktuxc.ktuxcnfb
OFFSET 4168
BBED> print
ktuxc.ktuxcnfb
--------------
sb2 ktuxcnfb #4168 1
BBED> modify 0x0000
File: /oradata/s102/system01.dbf (1)
Block: 9 Offsets: 4168 to 4679 Dba:0x00400009
------------------------------------------------------------------------
00000000 00000000 06001700 02800100 68000000 feffff7f 97014000 3a000c00
0400fe15 00000000 37000500 01006c1d 00000000 35003700 05003805 00000000
00000000 00000000 00000000 00000000 00000000 30000000 93014000 191f5300
00000000 09005f00 00000000 00000000 00000000 01000000 00000000 31000000
96014000 a03e5b00 00000000 09005c00 00000000 00000000 00000000 01000000
00000000 31000000 96014000 9e3e5b00 00000000 09000e00 00000000 00000000
00000000 01000000 00000000 30000000 93014000 f4bb4f00 00000000 09001600
00000000 00000000 00000000 01000000 00000000 31000000 96014000 c13a5b00
00000000 09004800 00000000 00000000 00000000 01000000 00000000 31000000
96014000 983e5b00 00000000 09006000 00000000 00000000 00000000 01000000
00000000 30000000 93014000 f2bb4f00 00000000 09001400 00000000 00000000
00000000 01000000 00000000 31000000 96014000 933e5b00 00000000 09006100
00000000 00000000 00000000 01000000 00000000 31000000 96014000 8d3e5b00
00000000 09004700 00000000 00000000 00000000 01000000 00000000 30000000
94014000 87d15900 00000000 09002100 00000000 00000000 00000000 01000000
00000000 30000000 94014000 211f5300 00000000 09001d00 00000000 00000000
<32 bytes per line>
9. Modify ktuxc.ktuxcfbp[0].ktufbuba to 0x00000000
BBED> set offset ktuxc.ktuxcfbp[0].ktufbuba
OFFSET 4192
BBED> print
ktuxc.ktuxcfbp[0].ktufbuba.kubadba
----------------------------------
ub4 kubadba #4192 0x00400197
BBED> modify 0x00000000
File: /oradata/s102/system01.dbf (1)
Block: 9 Offsets: 4192 to 4703 Dba:0x00400009
------------------------------------------------------------------------
00000000 3a000c00 0400fe15 00000000 37000500 01006c1d 00000000 35003700
05003805 00000000 00000000 00000000 00000000 00000000 00000000 30000000
93014000 191f5300 00000000 09005f00 00000000 00000000 00000000 01000000
00000000 31000000 96014000 a03e5b00 00000000 09005c00 00000000 00000000
00000000 01000000 00000000 31000000 96014000 9e3e5b00 00000000 09000e00
00000000 00000000 00000000 01000000 00000000 30000000 93014000 f4bb4f00
00000000 09001600 00000000 00000000 00000000 01000000 00000000 31000000
96014000 c13a5b00 00000000 09004800 00000000 00000000 00000000 01000000
00000000 31000000 96014000 983e5b00 00000000 09006000 00000000 00000000
00000000 01000000 00000000 30000000 93014000 f2bb4f00 00000000 09001400
00000000 00000000 00000000 01000000 00000000 31000000 96014000 933e5b00
00000000 09006100 00000000 00000000 00000000 01000000 00000000 31000000
96014000 8d3e5b00 00000000 09004700 00000000 00000000 00000000 01000000
00000000 30000000 94014000 87d15900 00000000 09002100 00000000 00000000
00000000 01000000 00000000 30000000 94014000 211f5300 00000000 09001d00
00000000 00000000 00000000 01000000 00000000 30000000 93014000 0d1f5300
<32 bytes per line>
BBED>
10. Disable the block Checksum by changing the kcbh.flg_kcbh-4 and kcbh.chkval_kcbh to 0x0000:
BBED> map
File: /oradata/s102/system01.dbf (1)
Block: 9 Dba:0x00400009
------------------------------------------------------------
Unlimited Undo Segment Header
struct kcbh, 20 bytes #0
struct ktech, 72 bytes #20
struct ktemh, 16 bytes #92
struct ktetb[6], 48 bytes #108
struct ktuxc, 104 bytes #4148
struct ktuxe[255], 10200 bytes #4252
ub4 tailchk #8188
BBED> print kcbh
struct kcbh, 20 bytes #0
ub1 type_kcbh #0 0x0e
ub1 frmt_kcbh #1 0xa2
ub1 spare1_kcbh #2 0x00
ub1 spare2_kcbh #3 0x00
ub4 rdba_kcbh #4 0x00400009
ub4 bas_kcbh #8 0x005b3f76
ub2 wrp_kcbh #12 0x0000
ub1 seq_kcbh #14 0x01
ub1 flg_kcbh #15 0x04 (KCBHFCKV)
ub2 chkval_kcbh #16 0xe264
ub2 spare3_kcbh #18 0x0000
BBED> set offset kcbh.flg_kcbh
OFFSET 15
BBED> print
kcbh.flg_kcbh
-------------
ub1 flg_kcbh #15 0x04 (KCBHFCKV)
BBED> modify 0x00
File: /oradata/s102/system01.dbf (1)
Block: 9 Offsets: 15 to 526 Dba:0x00400009
------------------------------------------------------------------------
0064e200 00000000 00000000 00000000 00000000 00060000 002f0000 00201000
00040000 00060000 00080000 00970140 00000000 00040000 00000000 00000000
00000000 00000000 00000000 00060000 00000000 00000000 00000000 400a0040
00070000 00110040 00080000 00810140 00080000 00890140 00080000 00910140
00080000 00990140 00080000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<32 bytes per line>
BBED> set offset kcbh.chkval_kcbh
OFFSET 16
BBED> print
kcbh.chkval_kcbh
----------------
ub2 chkval_kcbh #16 0xe264
BBED> modify 0x0000
File: /oradata/s102/system01.dbf (1)
Block: 9 Offsets: 16 to 527 Dba:0x00400009
------------------------------------------------------------------------
00000000 00000000 00000000 00000000 00000000 06000000 2f000000 20100000
04000000 06000000 08000000 97014000 00000000 04000000 00000000 00000000
00000000 00000000 00000000 06000000 00000000 00000000 00000040 0a004000
07000000 11004000 08000000 81014000 08000000 89014000 08000000 91014000
08000000 99014000 08000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<32 bytes per line>
11. Verify the the block has no corruptions:
BBED> verify
DBVERIFY - Verification starting
FILE = /oradata/s102/system01.dbf
BLOCK = 9
DBVERIFY - Verification complete
Total Blocks Examined : 1
Total Blocks Processed (Data) : 0
Total Blocks Failing (Data) : 0
Total Blocks Processed (Index): 0
Total Blocks Failing (Index): 0
Total Blocks Empty : 0
Total Blocks Marked Corrupt : 0
Total Blocks Influx : 0
12. exit, open the database and shrink the system rollback segment:
BBED> exit
[oracle#arem example]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.3.0 - Production on Thu Sep 27 10:28:00 2007
Copyright (c) 1982, 2006, Oracle. All Rights Reserved.
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 1260696 bytes
Variable Size 62915432 bytes
Database Buffers 100663296 bytes
Redo Buffers 2932736 bytes
Database mounted.
Database opened.
SQL> alter rollback segment system shrink;
Rollback segment altered.
SQL>
I have a .i file which I have compiled but not linked using the SiFive risc-v compiler as follows:
../riscv64-unknown-elf-gcc-8.2.0-2019.05.3-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gcc clock.i
However when I do a readelf -S on the compiled object file the .text section is 0 bytes:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000034 000000 00 AX 0 0 2
[ 2] .data PROGBITS 00000000 000034 000000 00 WA 0 0 1
[ 3] .bss NOBITS 00000000 000034 000000 00 WA 0 0 1
[ 4] .text.getTime PROGBITS 00000000 000034 00003a 00 AX 0 0 2
[ 5] .rela.text.ge RELA 00000000 000484 0000c0 0c I 18 4 4
[ 6] .text.timeGap PROGBITS 00000000 00006e 00002e 00 AX 0 0 2
[ 7] .rela.text.ti RELA 00000000 000544 000024 0c I 18 6 4
[ 8] .text.applyTO PROGBITS 00000000 00009c 000038 00 AX 0 0 2
[ 9] .rela.text.ap RELA 00000000 000568 0000c0 0c I 18 8 4
[10] .text.clearTO PROGBITS 00000000 0000d4 000038 00 AX 0 0 2
[11] .rela.text.cl RELA 00000000 000628 0000c0 0c I 18 10 4
[12] .rodata.getTi PROGBITS 00000000 00010c 00000c 01 AMS 0 0 4
[13] .rodata.__func__. PROGBITS 00000000 000118 00000c 00 A 0 0 4
[14] .rodata.__func__. PROGBITS 00000000 000124 00000c 00 A 0 0 4
[15] .rodata.__func__. PROGBITS 00000000 000130 00000c 00 A 0 0 4
[16] .comment PROGBITS 00000000 00013c 000029 01 MS 0 0 1
[17] .riscv.attributes LOPROC+0x3 00000000 000165 00001f 00 0 0 1
[18] .symtab SYMTAB 00000000 000184 000240 10 19 31 4
[19] .strtab STRTAB 00000000 0003c4 0000be 00 0 0 1
[20] .shstrtab STRTAB 00000000 0006e8 000100 00 0 0 1
If I do a size on the compiled object file I get a size of 264 bytes:
text data bss dec hex filename
264 0 0 264 108 clock.o
If I do an nm --print-size I get the following:
U __assert_func
00000000 0000000c r __func__.3507
00000000 0000000c r __func__.3518
00000000 0000000c r __func__.3522
0000000c t .L11
00000036 t .L12
00000034 t .L14
00000036 t .L18
00000034 t .L2
00000034 t .L20
00000032 t .L3
0000001e t .L8
00000000 r .LANCHOR0
00000000 r .LANCHOR1
00000000 r .LANCHOR2
00000000 r .LC0
00000004 r .LC1
00000000 00000038 T applyTO
00000000 00000038 T clearTO
00000000 0000003a T getTime
00000000 0000002e T timeGap
Which to me the size would be 0x38 + 0x38 + 0x3A + 0x2E = 0xD8 (216) bytes.
How can I calculate the size of a compiled object file?
Your object file is compiled with -ffunction-sections, a special flag which allocates each function to it's dedicated section. You can see individual .texts for each function in readelf's output:
[ 4] .text.getTime PROGBITS 00000000 000034 00003a 00 AX 0 0 2
...
[ 6] .text.timeGap PROGBITS 00000000 00006e 00002e 00 AX 0 0 2
...
To get full code size you'll need to sum sizes for each section starting with ".text". A Perl one-liner:
$ readelf ... | perl -ne 'if(/ \.text/) { s/^.*\] *//; $sz += hex((split(/ +/))[4]); print "$sz\n"; }' 0
58
104
160
216 <-- Full size
I make performance measurements on the Raspberry Pi and would like to have higher resolution then just clock_gettime().
Therefor I need to enable the CPU register PMUSERENR.
According to /proc/cpuinfo on my Raspberry Pi I have an "ARMv7 Processor rev 5 (v7l)". So I downloaded the architecture reference manual and found that I have to use:
CRn = c9, opc1 = 0, CRm = c14, opc2 = 0
asm ("MCR p15, 0, %0, C9, C14, 0\n\t" :: "r"(1));
But when using this code in a kernel module, I get following oops:
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.604846] Internal error: Oops: 5 [#1] SMP ARM
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.715199] Process insmod (pid: 2944, stack limit = 0xac80e210)
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.722399] Stack: (0xac80fe90 to 0xac810000)
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.727920] fe80: 7f1ba0f8 00007fff 80098128 ac80fea8
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.738472] fea0: 80578128 0000002d 00000000 7f1ba0f8 7f1ba0f8 7f1ba26c 7f1ba264 7f1ba134
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.749092] fec0: ac80e000 8057608c ac80feec ac80fed8 8057608c 00000000 00000000 00000000
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.759724] fee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
pi#raspberrypi ~/projects/timer $
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.770389] ff00: 00000000 00000000 00000000 00000000 76f5e948 00007390 00000000 76f7b390
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.781147] ff20: 76f5e948 b91a2390 ac80e000 00000000 ac80ffa4 ac80ff40 8009b6c4 80099714
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.792000] ff40: b919b000 00007390 b91a0598 b91a0457 b91a22c8 0000026c 000002ac 00000000
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.802930] ff60: 00000000 00000000 0000001f 00000020 0000000c 0000000a 00000009 00000000
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.813947] ff80: 7ea4371c 00000000 55afc028 00000080 8000fc28 ac80e000 00000000 ac80ffa8
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.825056] ffa0: 8000fa20 8009b5f0 7ea4371c 00000000 76f74000 00007390 76f5e948 76f74000
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.836170] ffc0: 7ea4371c 00000000 55afc028 00000080 55afbf78 00007390 76f5e948 00000000
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.847338] ffe0: 00000000 7ea436c4 76f55fb4 76ec0534 60000010 76f74000 00000000 00000000
Message from syslogd#raspberrypi at Apr 29 20:58:12 ...
kernel:[ 84.880715] Code: e51b3084 e1530005 e2455008 0a000009 (e5953014)
I am new to kernel modules, so I do not know which direction I should go. Is there a good way to debug such things?
Linux kernel comes with a PMU driver. You could just leverage that. I would write a tutorial for you, but why reinvent the wheel when this guy explains it so well:
http://www.carbondesignsystems.com/virtual-prototype-blog/using-the-arm-performance-monitor-unit-pmu-linux-driver
I'm using the following function from the book "Windows System Programming 4th" by Johnson M. Hart. To acquaint myself with the Win32 API. I'm also inspecting the function with Windbg.
When inspecting the parameter that points to the buffer that receives the data read from the file. I get the output below from the debugger. Can someone explain how to use windbg to inspect the lpBuffer?
#include "Everything.h"
#define BUF_SIZE 256
BOOL cci_f (LPCTSTR fIn, LPCTSTR fOut, DWORD shift)
{
HANDLE hIn, hOut;
DWORD nIn, nOut, iCopy;
BYTE buffer [BUF_SIZE], bShift = (BYTE)shift;
BOOL writeOK = TRUE;
hIn = CreateFile (fIn, GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if (hIn == INVALID_HANDLE_VALUE) return FALSE;
hOut = CreateFile (fOut, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
if (hOut == INVALID_HANDLE_VALUE) {
CloseHandle(hIn);
return FALSE;
}
while (writeOK && ReadFile (hIn, buffer, BUF_SIZE, &nIn, NULL) && nIn > 0) {
for (iCopy = 0; iCopy < nIn; iCopy++)
buffer[iCopy] = buffer[iCopy] + bShift;
writeOK = WriteFile (hOut, buffer, nIn, &nOut, NULL);
}
CloseHandle (hIn);
CloseHandle (hOut);
return writeOK;
}
0:000> bp kernel32!readfile
0:000> g
Breakpoint 1 hit
eax=00000000 ebx=00000000 ecx=0018bf0c edx=00000030 esi=00000030 edi=0018ff20
eip=77383f11 esp=0018bddc ebp=0018be20 iopl=0 nv up ei ng nz ac po cy
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000293
kernel32!ReadFile:
77383f11 ff25ec093877 jmp dword ptr [kernel32!_imp__ReadFile (773809ec)] ds:002b:773809ec={KERNELBASE!ReadFile (75efdc4a)}
0:000> k
ChildEBP RetAddr
0018be20 00411551 kernel32!ReadFile
0018ff44 00411b50 cpW!main+0x181 [c:\microsoft_press\wsp4_examples\chaptr01\cpw.c # 31]
0018ff88 7738338a cpW!__tmainCRTStartup+0x122 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c # 555]
0018ff94 779b9f72 kernel32!BaseThreadInitThunk+0xe
0018ffd4 779b9f45 ntdll!__RtlUserThreadStart+0x70
0018ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> dd ebp
0018be20 0018ff44 00411551 00000030 0018bf0c
0018be30 00004000 0018ff20 00000000 0041757c
0018be40 00000001 00000000 cccccccc cccccccc
0018be50 cccccccc cccccccc cccccccc cccccccc
0018be60 cccccccc cccccccc cccccccc cccccccc
0018be70 cccccccc cccccccc cccccccc cccccccc
0018be80 cccccccc cccccccc cccccccc cccccccc
0018be90 cccccccc cccccccc cccccccc cccccccc
0:000> da 0018bf0c
0018bf0c "................................"
0018bf2c "................................"
0018bf4c "................................"
0018bf6c "................................"
0018bf8c "................................"
0018bfac "................................"
0018bfcc "................................"
0018bfec "................................"
0018c00c "................................"
0018c02c "................................"
0018c04c "................................"
0018c06c "................................"
Additional debug output below after suggestions.
0:000> lm
start end module name
00400000 0040a000 cci (deferred)
71580000 71656000 MSVCR110 (deferred)
71660000 71703000 MSVCR90 (deferred)
72660000 72666000 Utility_4_0 (deferred)
76630000 76677000 KERNELBASE (deferred)
76950000 76a60000 kernel32 (deferred)
771d0000 77350000 ntdll (pdb symbols) c:\symbol\wntdll.pdb\69DDFBCBBC14421D8CB974F8EDC414102\wntdll.pdb
0:000> .sympath+ C:\Microsoft_Press\WSP4_Examples\Projects2008\cci\Debug
Symbol search path is: SRV*c:\symbol*http://msdl.microsoft.com/download/symbols;C:\Microsoft_Press\WSP4_Examples\Projects2008\cci\Debug
Expanded Symbol search path is: srv*c:\symbol*http://msdl.microsoft.com/download/symbols;c:\microsoft_press\wsp4_examples\projects2008\cci\debug
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*c:\symbol*http://msdl.microsoft.com/download/symbols
OK C:\Microsoft_Press\WSP4_Examples\Projects2008\cci\Debug
0:000> bp cci!main
*** WARNING: Unable to verify checksum for cci.exe
0:000> g
Breakpoint 0 hit
eax=71648634 ebx=00000000 ecx=0048e198 edx=00000000 esi=00000001 edi=00000000
eip=00401020 esp=0018ff4c ebp=0018ff88 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
cci!main:
00401020 55 push ebp
0:000> bp kernel32!Readfile
0:000> g
Breakpoint 1 hit
eax=00000000 ebx=00000000 ecx=0018fd24 edx=0000003c esi=0000003c edi=0018fe44
eip=76963f11 esp=0018fbdc ebp=0018fc20 iopl=0 nv up ei ng nz ac po cy
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000293
kernel32!ReadFile:
76963f11 ff25ec099676 jmp dword ptr [kernel32!_imp__ReadFile (769609ec)] ds:002b:769609ec={KERNELBASE!ReadFile (7663dc4a)}
0:000> k
ChildEBP RetAddr
0018fc20 004011f3 kernel32!ReadFile
0018fe68 004010a3 cci!cci_f+0xe3 [c:\microsoft_press\wsp4_examples\chaptr02\cci_f.c # 29]
0018ff48 00401765 cci!main+0x83 [c:\microsoft_press\wsp4_examples\chaptr02\cci.c # 24]
0018ff88 7696338a cci!__tmainCRTStartup+0xfd [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c # 536]
0018ff94 77209f72 kernel32!BaseThreadInitThunk+0xe
0018ffd4 77209f45 ntdll!__RtlUserThreadStart+0x70
0018ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> r esp
esp=0018fbdc
0:000> dd 0018fbdc
0018fbdc 76963ee7 0000003c 0018fd24 00000100
0018fbec 0018fe44 00000000 988c6ffa 0018fe68
0018fbfc 0018fc3c 00000000 769653d0 0018fbf4
0018fc0c 0018fc3c 0018ff78 76a04643 ee02ad2a
0018fc1c fffffffe 0018fe68 004011f3 0000003c
0018fc2c 0018fd24 00000100 0018fe44 00000000
0018fc3c 0018ff48 0018fe7c 00000000 cccccccc
0018fc4c cccccccc cccccccc cccccccc cccccccc
0:000> !handle 0000003c f
Handle 3c
Type File
Attributes 0
GrantedAccess 0x120089:
ReadControl,Synch
Read/List,ReadEA,ReadAttr
HandleCount 2
PointerCount 19
No Object Specific Information available
0:000> da 0018fd24
0018fd24 "................................"
0018fd44 "................................"
0018fd64 "................................"
0018fd84 "................................"
0018fda4 "................................"
0018fdc4 "................................"
0018fde4 "................................"
0018fe04 "................................"
0018fe24 "................................"
0018fe44 ""
0:000> r ebp
ebp=0018fc20
0:000> dd 0018fc20
0018fc20 0018fe68 004011f3 0000003c 0018fd24
0018fc30 00000100 0018fe44 00000000 0018ff48
0018fc40 0018fe7c 00000000 cccccccc cccccccc
0018fc50 cccccccc cccccccc cccccccc cccccccc
0018fc60 cccccccc cccccccc cccccccc cccccccc
0018fc70 cccccccc cccccccc cccccccc cccccccc
0018fc80 cccccccc cccccccc cccccccc cccccccc
0018fc90 cccccccc cccccccc cccccccc cccccccc
0:000> da 0018fd24
0018fd24 "................................"
0018fd44 "................................"
0018fd64 "................................"
0018fd84 "................................"
0018fda4 "................................"
0018fdc4 "................................"
0018fde4 "................................"
0018fe04 "................................"
0018fe24 "................................"
0018fe44 ""
Dumping the Kernel32!Writefile lBuffer shows the data to be written to the file. I'm unclear on why the kernel32!ReadFile is not showing the data in it lpBuffer argument.
0:000> bp kernel32!writefile
0:000> g
Breakpoint 2 hit
eax=00000040 ebx=00000000 ecx=0018fe38 edx=00000000 esi=0018fc3c edi=0018fe68
eip=769617ad esp=0018fc08 ebp=0018fc20 iopl=0 nv up ei ng nz ac po cy
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000293
kernel32!WriteFile:
769617ad ff25e4099676 jmp dword ptr [kernel32!_imp__WriteFile (769609e4)] ds:002b:769609e4={KERNELBASE!WriteFile (7663ddbc)}
0:000> k
ChildEBP RetAddr
0018fc20 0040125b kernel32!WriteFile
0018fe68 004010a3 cci!cci_f+0x14b [c:\microsoft_press\wsp4_examples\chaptr02\cci_f.c # 36]
0018ff48 00401765 cci!main+0x83 [c:\microsoft_press\wsp4_examples\chaptr02\cci.c # 24]
0018ff88 7696338a cci!__tmainCRTStartup+0xfd [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c # 536]
0018ff94 77209f72 kernel32!BaseThreadInitThunk+0xe
0018ffd4 77209f45 ntdll!__RtlUserThreadStart+0x70
0018ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> dd 0018fc20
0018fc20 0018fe68 0040125b 00000040 0018fd24
0018fc30 00000100 0018fe38 00000000 0018ff48
0018fc40 0018fe7c 00000000 cccccccc cccccccc
0018fc50 cccccccc cccccccc cccccccc cccccccc
0018fc60 cccccccc cccccccc cccccccc cccccccc
0018fc70 cccccccc cccccccc cccccccc cccccccc
0018fc80 cccccccc cccccccc cccccccc cccccccc
0018fc90 cccccccc cccccccc cccccccc cccccccc
0:000> da 0018fd24
0018fd24 "9:(86:::##98<?8:#;<A<;..9:(86:::"
0018fd44 "##98<?8:#;<A<;..9:(86:::##98<?8:"
0018fd64 "#;<A<;..9:(86:::##98<?8:#;<A<;.."
0018fd84 "9:(86:::##98<?8:#;<A<;..9:(86:::"
0018fda4 "##98<?8:#;<A<;..9:(86:::##98<?8:"
0018fdc4 "#;<A<;..9:(86:::##98<?8:#;<A<;.."
0018fde4 "9:(86:::##98<?8:#;<A<;..9:(86:::"
0018fe04 "##98<?8:#;<A<;..9:(86:::##98<?8:"
0018fe24 "........"
Thanks to the insight provided by the community. I'm able to view data within lpBuffer by first setting a breakpoint at Kernel32!ReadFile. Then executing gu (The gu command causes the target to execute until the current function is complete). Thereafter I can dump the buffer. Which now shows the data I'm interested in.
BOOL WINAPI ReadFile(
_In_ HANDLE hFile,
_Out_ LPVOID lpBuffer,
_In_ DWORD nNumberOfBytesToRead,
_Out_opt_ LPDWORD lpNumberOfBytesRead,
_Inout_opt_ LPOVERLAPPED lpOverlapped
);
When you have broken on ReadFile the lpBuffer will contain rubbish/ garbage/ zeros/ or pre initialised content based on how you allocated and initialised the buffer this buffer will be filled up with the content of the file only after you return from the API to step out of the function use gu (goup) and examine the buffer (save the address of buffer first for examining later address of buffer should be at #esp+08 when you have broken on ReadFile in kernel32.dll on a 32 bit system
the walk through below creates a new file in current directory then writes to it then resets the file position for reading to beginning of the file reads the file and prints the content to stdout and quits after Closing the handle .
cdb is console mode windbg
-c switch takes commands to execute on events
g main executes file till main to avoid uninteresting breaks in
ReadFile
bp kernel32!ReadFile sets a breakpoint on the API
g to execute the file so that it breaks in our breakpoint
bc * to clear any breakpoints (advisable to form this habit when
scripting)
r $t0 = poi(#esp+8) to save the pointer to lpBuffer
poi(#esp+0) is always return address
poi(#esp+4) is always first argument when broken on Function Start
in 32 bit systems.
.echo is to output a comment .
db #$t0 l20 prints the 1st 20 bytes of lpBuffer prior to Executing ReadFile()
gu is to goup
.echo is to output a comment .
db #$t0 l20 prints the 1st 20 bytes of lpBuffer post Execution of ReadFile()
g;q is to continue and quit when finished executing the file
readfile>type readfile.cpp & %compile% readfile.cpp & readfile.exe
#include <stdio.h>
#include <Windows.h>
int main(void) {
char writein[] = {"Iam going to write me in\n"};
char readin [] = {"Iam rubbish Iam garbage Readfile will clean me up\n" };
DWORD bytesreadoutin = 0;
BOOL result = FALSE;
HANDLE hFile = CreateFileA("mynewtxt.txt",GENERIC_ALL,FILE_SHARE_WRITE |
FILE_SHARE_READ,NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL,NULL);
if (INVALID_HANDLE_VALUE != hFile) {
if ((result = WriteFile(
hFile,writein,sizeof(writein),&bytesreadoutin,NULL)) == TRUE ) {
if (bytesreadoutin == sizeof(writein)) {
if ( INVALID_SET_FILE_POINTER != SetFilePointer(
hFile,NULL,NULL,FILE_BEGIN) ) {
if (( result = ReadFile(
hFile,readin,sizeof(writein),&bytesreadoutin,
NULL))== TRUE) {
printf(readin);
}
}
}
}
CloseHandle(hFile);
}
return 0;
}Setting environment for using Microsoft Visual Studio 2010 x86 tools.
readfile.cpp
Press any key to continue . . .
I am going to write me in
with windbg
readfile>cdb -c "g main;bp kernel32!ReadFile;g;bc *;r $t0 = poi(#esp+8);.echo =============buffer contents pre readfile================;db #$t0 l20;gu;.echo ======================buffer contents post readfile=================;db #$t0 l20;g;q" readfile.exe
ntdll!DbgBreakPoint:
7c90120e cc int 3
0:000> cdb: Reading initial command 'g main;bp kernel32!ReadFile;g;bc *;r $t0 =
poi(#esp+8);.echo =============buffer contents pre readfile================;db #
$t0 l20;gu;.echo ======================buffer contents post readfile============
=====;db #$t0 l20;g;q'
Breakpoint 0 hit
=============buffer contents pre readfile================
0013ff34 49 20 61 6d 20 72 75 62-62 69 73 68 20 49 20 61 I am rubbish I a
0013ff44 6d 20 67 61 72 62 61 67-65 49 20 77 69 6c 6c 20 m garbageI will
======================buffer contents post readfile=================
0013ff34 49 20 61 6d 20 67 6f 69-6e 67 20 74 6f 20 77 72 I am going to wr
0013ff44 69 74 65 20 6d 65 20 69-6e 0a 00 77 69 6c 6c 20 ite me in..will
I am going to write me in
quit:
To Log All ReadFile calls write a simple script with all the commands in .block {} and set a conditional breakpoint like bp kernel32!ReadFile "$$>a< X:\\blah.ext"
be aware that ReadFile is a Very Busy Api and in general you do not want
to set permanent breaks in busy apis as that may lead to very poor performance
or an undesirable slowness in the session and may introduce severe problems when debugging problems with time dependent code
script file contents
0:004> .shell -ci " " type c:\\readfile.txt
.block {
r $t0 = poi(#esp+0x8);
.echo ========================================pre&post===========================
db #$t0 l10;
gu;
db #$t0 l10;
g;
}.shell: Process exited
result
0:002> $$ start of logging ReadFile
0:002> bl
0 e 7c801812 0001 (0001) 0:**** kernel32!ReadFile "$$>a< c:\\readfile.txt"
0:002> .bpcmds
bp0 0x7c801812 "$$>a< c:\\readfile.txt";
0:002> g
========================================pre&post===========================
0011fa10 00 00 00 00 00 00 00 00-60 00 00 00 00 00 00 00 ........`.......
0011fa10 49 54 53 46 03 00 00 00-60 00 00 00 01 00 00 00 ITSF....`.......
========================================pre&post===========================
001271d8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
001271d8 49 54 53 50 01 00 00 00-54 00 00 00 0a 00 00 00 ITSP....T.......
========================================pre&post===========================
000e9038 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
000e9038 50 4d 47 4c 10 0b 00 00-00 00 00 00 ff ff ff ff PMGL............
========================================pre&post===========================
009eed38 f0 f9 11 00 a8 ed 9e 00-fd f3 e2 65 f0 f9 11 00 ...........e....
009eed38 1e 00 11 00 a8 ed 9e 00-fd f3 e2 65 f0 f9 11 00 ...........e....
========================================pre&post===========================
0011ef42 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0011ef42 02 00 0c 00 55 00 6e 00-63 00 6f 00 6d 00 70 00 ....U.n.c.o.m.p.
========================================pre&post===========================
009ef018 50 0a 15 00 d8 6b 3d 00-34 f0 9e 00 6c f0 9e 00 P....k=.4...l...
009ef018 03 00 00 00 d8 6b 3d 00-34 f0 9e 00 6c f0 9e 00 .....k=.4...l...
========================================pre&post===========================
Here is a sequence of Windbg commands to see what bytes received in lpBuffer when ReadFile is called.
bp ReadFile
r $t1 = dwo(esp+8) ;lpBuffer
pt ;execute till return
db #$t1 ;dump bytes in lpBuffer
You can find a simple Windbg script of intercepting ReadFile calls here.
I have a script that initializes a driver on startup, which worked beautifully before I enabled kernel tracing and recompiled the kernel to try and debug an issue with a piece of software. If I try to initialize the driver in any way (modprobe, insmod, etc) this output prints to the screen:
[ 26.263308] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 26.263322] IP: [<c108664d>] trace_module_notify+0x16b/0x20a
[ 26.263325] *pde = 00000000
[ 26.263329] Oops: 0000 [#1] PREEMPT SMP
[ 26.263335] Modules linked in: phddrv(O+)
[ 26.263343] Pid: 704, comm: insmod Tainted: G O 3.6.3-rt9 #21 Advanced Digital Logic, Inc CB4053/ADLS15PC
[ 26.263346] EIP: 0060:[<c108664d>] EFLAGS: 00010213 CPU: 0
[ 26.263350] EIP is at trace_module_notify+0x16b/0x20a
[ 26.263353] EAX: ee6e9274 EBX: f082550c ECX: ee6e920c EDX: f082550c
[ 26.263356] ESI: 00000000 EDI: ee6e92dc EBP: ee6ebf4c ESP: ee6ebf24
[ 26.263359] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 26.263362] CR0: 8005003b CR2: 00000000 CR3: 2f2ea000 CR4: 000007d0
[ 26.263365] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 26.263367] DR6: ffff0ff0 DR7: 00000400
[ 26.263371] Process insmod (pid: 704, ti=ee6ea000 task=ef218000 task.ti=ee6ea000)
[ 26.263372] Stack:
[ 26.263381] ee6e9274 ee6e9344 ee6e92dc ee6e920c ee6e9274 ee6e9344 c2086424 c15a5d58
[ 26.263388] 00000000 00000001 ee6ebf68 c1046d33 f082550c c15a51bc c15a3778 00000000
[ 26.263396] c15a3790 ee6ebf8c c1046fa9 fffffffd 00000000 f082550c 00000001 f082550c
[ 26.263397] Call Trace:
[ 26.263407] [<c1046d33>] notifier_call_chain+0x2b/0x4d
[ 26.263413] [<c1046fa9>] __blocking_notifier_call_chain+0x3c/0x51
[ 26.263419] [<c1046fcf>] blocking_notifier_call_chain+0x11/0x13
[ 26.263426] [<c10671b7>] sys_init_module+0x57/0x190
[ 26.263434] [<c13a3d10>] sysenter_do_call+0x12/0x26
[ 26.263489] Code: 00 c7 42 04 64 5d 5a c1 89 15 64 5d 5a c1 89 45 ec 8d 42 74 83 c2 0c 89 45 e8 89 55 e4 eb 19 57 8b 4d e4 89 da ff 75 ec ff 75 e8 <8b> 06 83 c6 04 e8 c2 fb ff ff 83 c4 0c 3b 75 f0 72 e2 eb 77 b8
[ 26.263495] EIP: [<c108664d>] trace_module_notify+0x16b/0x20a SS:ESP 0068:ee6ebf24
[ 26.263497] CR2: 0000000000000000
[ 26.267381] ---[ end trace 0000000000000002 ]---
Any hint as to what is going on would be greatly appreciated!
I got similar issue as yours (almost the same stack trace of panic).
The root cause on my side is that after I changed the kernel config (enable trace point) I only rebuilt the kernel bzImage but forgot to rebuilt the ko modules! That may cause some execution mismatch between the new kernel and old ko modules.
After rebuild and update both kernel image and ko modules, the issue is gone.
Somewhere in the driver there is a NULL pointer. A pointer variabile has value NULL and the driver is trying to use it.
myPtr->value; /* if myPtr is NULL, this will raise the kernel oops */
You have to debug the driver to find where and why there is a NULL pointer