I can’t repro this, but I’ll keep looking.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Albrecht Frenzel
Sent: Thursday, July 27, 2006 2:58 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Executing .excr from a macro file fails to update
the Calls Window
Yes, I see the results of !analyze -v, but after executing .excr, the
Calls window looks, as .excr hadn’t been executed.
Please see the details below:
=======================================================================
Content of Analyze.mac:
lm
!analyze -v
~9s
.ecxr
kb
=======================================================================
Macro file execution via -c option:
0:009> $$<d:>0:009> lm
start end module name
007a0000 007be000 DriveLocker (deferred)
…
01000000 010d6000 App (private pdb symbols) …
…
7d590000 7dd83000 shell32 (deferred)
Unloaded modules:
76060000 761b6000 SETUPAPI.DLL
76060000 761b6000 SETUPAPI.DLL
76060000 761b6000 SETUPAPI.DLL
0:009> !analyze -v
****************************************************************
Exception Analysis
*
*****************************************************************
…
FAULTING_IP:
App!CSrbIo::MakeSrbIo10+c […]
0102215c 8b08 mov ecx,dword ptr [eax]
EXCEPTION_RECORD: ffffffff – (.exr ffffffffffffffff)
ExceptionAddress: 0102215c (App!CSrbIo::MakeSrbIo10+0x0000000c)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00012730
Attempt to read from address 00012730
DEFAULT_BUCKET_ID: BAD_PTR_DEREFERENCE
PROCESS_NAME: App.exe
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
referenced memory at “0x%08lx”. The memory could not be “%s”.
READ_ADDRESS: 00012730
BUGCHECK_STR: ACCESS_VIOLATION
ORIGINAL_CAB_PATH: …\0280506909.cab
LAST_CONTROL_TRANSFER: from 010536a0 to 0102215c
STACK_TEXT:
00a0f244 010536a0 00012730 00000043 00000000 App!CSrbIo::MakeSrbIo10+0xc
[…]
00a0f2a4 010508bd 00a0f2c8 00000000 00a0f300
App!CScsiMmcWocd::EReadFormattedToc+0x160 […] 00a0f2f0 010520a0
00a0f300 002b3b30 00000000 App!CScsiMmcWocd::TMrwMediaInNonMrwDrive+0x5d
[…]
00a0f318 0103c94e 00000046 00000000 002bcf48
App!CScsiMmcWocd::TMediaIsMrw+0x70 […]
00a0f454 0103d35d 006275e0 002b3b30 0090fe94
App!EDeviceStateToSysinfo+0x25e […] 00a0fe60 0103e542 002b38ec
00000001 00000002 App!CFpIpcServer::Handler+0x27d […]
00a0fe78 01043ab3 002b38ec 002bcf48 00000001
App!CFpIpcServer::Handler_static+0x22 […] 00a0ff20 01043d05 002b38ec
00000000 00000000
App!CIpcppServer::EReqHandler+0x83 […]
00a0ff38 0101d598 002b38e8 0090fea4 0090fe94
App!CIpcppServer::EStaticReqHandler+0x15 […] 00a0ff4c 0101d414
0062621c 00000001 00000000
App!CThreadManager::Vrt_ProcessThreadCall+0x38 […]
00a0ff68 0101d45d 0062621c 0101858c 0062621c
App!CThreadManager::ThreadHoldRoutine+0x34 […] 00a0ff70 0101858c
0062621c 00000000 00626180
App!CThreadManager::U32Stat_ThreadHoldRoutine+0xd […] 00a0ff80
7c349565 00627208 00000000 00000000 App!U32StartThreadHelper+0xc […]
00a0ffb4 7c80b50b 00627218 00000000 00000000 msvcr71!_threadstartex+0x6f
[…] 00a0ffec 00000000 7c3494f6 00627218 00000000
kernel32!BaseThreadStart+0x37
STACK_COMMAND: ~9s; .ecxr ; kb
FAULTING_THREAD: 00000640
PRIMARY_PROBLEM_CLASS: BAD_PTR_DEREFERENCE
FOLLOWUP_IP:
App!CSrbIo::MakeSrbIo10+c […]
0102215c 8b08 mov ecx,dword ptr [eax]
FAULTING_SOURCE_CODE:
472: {
474:
475: zB *pbCdb;
> 476: SetupSrbIo(pAddr,10,enumTxfer,cbBufferSize,pbBuffer);
477: pbCdb = PbCdbGet();
478: pbCdb[0] = bCommand;
479: pbCdb[1] = (pAddr->scsiAddr.bLun << 5);
480: PutLToMsbA4b(u32PosByte2To5, &pbCdb[2]);
481: PutIToMsbA2b(u16SizeByte78, &pbCdb[7]);
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: App!CSrbIo::MakeSrbIo10+c
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: App
IMAGE_NAME: App.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 44338f93
FAILURE_BUCKET_ID: ACCESS_VIOLATION_App!CSrbIo::MakeSrbIo10+c
BUCKET_ID: ACCESS_VIOLATION_App!CSrbIo::MakeSrbIo10+c
Followup: MachineOwner
---------
0:009> ~9s
eax=00002000 ebx=80070000 ecx=00002000 edx=00000000 esi=00000320
edi=00000000
eip=7c92eb94 esp=00a09600 ebp=00a09664 iopl=0 nv up ei ng
nz ac pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000297
ntdll!KiFastSystemCallRet:
7c92eb94 c3 ret
0:009> .ecxr
eax=00012730 ebx=00000014 ecx=00000003 edx=00000051 esi=00628cd0
edi=00000014
eip=0102215c esp=00a0f244 ebp=002bf58c iopl=0 nv up ei pl
nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00010202
App!CSrbIo::MakeSrbIo10+0xc:
0102215c 8b08 mov ecx,dword ptr [eax]
ds:0023:00012730=???
0:009> kb
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
00a0f244 010536a0 00012730 00000043 00000000 App!CSrbIo::MakeSrbIo10+0xc
[…]
00a0f2a4 010508bd 00a0f2c8 00000000 00a0f300
App!CScsiMmcWocd::EReadFormattedToc+0x160 […] 00a0f2f0 010520a0
00a0f300 002b3b30 00000000 App!CScsiMmcWocd::TMrwMediaInNonMrwDrive+0x5d
[…]
00a0f318 0103c94e 00000046 00000000 002bcf48
App!CScsiMmcWocd::TMediaIsMrw+0x70 […]
00a0f454 0103d35d 006275e0 002b3b30 0090fe94
App!EDeviceStateToSysinfo+0x25e […] 00a0fe60 0103e542 002b38ec
00000001 00000002 App!CFpIpcServer::Handler+0x27d […]
00a0fe78 01043ab3 002b38ec 002bcf48 00000001
App!CFpIpcServer::Handler_static+0x22 […] 00a0ff20 01043d05 002b38ec
00000000 00000000
App!CIpcppServer::EReqHandler+0x83 […]
00a0ff38 0101d598 002b38e8 0090fea4 0090fe94
App!CIpcppServer::EStaticReqHandler+0x15 […] 00a0ff4c 0101d414
0062621c 00000001 00000000
App!CThreadManager::Vrt_ProcessThreadCall+0x38 […]
00a0ff68 0101d45d 0062621c 0101858c 0062621c
App!CThreadManager::ThreadHoldRoutine+0x34 […] 00a0ff70 0101858c
0062621c 00000000 00626180
App!CThreadManager::U32Stat_ThreadHoldRoutine+0xd […] 00a0ff80
7c349565 00627208 00000000 00000000 App!U32StartThreadHelper+0xc […]
00a0ffb4 7c80b50b 00627218 00000000 00000000 msvcr71!_threadstartex+0x6f
[…] 00a0ffec 00000000 7c3494f6 00627218 00000000
kernel32!BaseThreadStart+0x37
==================================================================
Content of WinDbg Calls window - Frames00 through 0d shold not appear
here after executing .ecxr:
00 ntdll!KiFastSystemCallRet
01 ntdll!ZwWaitForSingleObject+0xc
02 kernel32!WaitForSingleObjectEx+0xa8
03 kernel32!WaitForSingleObject+0x12
04 faultrep!MyCallNamedPipe+0x15b
05 faultrep!StartManifestReport+0x1cd
06 faultrep!ReportFault+0x573
07 kernel32!UnhandledExceptionFilter+0x4cf
08 msvcr71!_XcptFilter+0x15f
09 msvcr71!_threadstartex+0x86
0a msvcr71!_except_handler3+0x61
0b ntdll!ExecuteHandler2+0x26
0c ntdll!ExecuteHandler+0x24
0d ntdll!KiUserExceptionDispatcher+0xe
0e App!CSrbIo::MakeSrbIo10+0xc
0f App!CScsiMmcWocd::EReadFormattedToc+0x160
10 App!CScsiMmcWocd::TMrwMediaInNonMrwDrive+0x5d
11 App!CScsiMmcWocd::TMediaIsMrw+0x70
12 App!EDeviceStateToSysinfo+0x25e
13 App!CFpIpcServer::Handler+0x27d
14 App!CFpIpcServer::Handler_static+0x22
15 App!CIpcppServer::EReqHandler+0x83
16 App!CIpcppServer::EStaticReqHandler+0x15
17 App!CThreadManager::Vrt_ProcessThreadCall+0x38
18 App!CThreadManager::ThreadHoldRoutine+0x34
19 App!CThreadManager::U32Stat_ThreadHoldRoutine+0xd
1a App!U32StartThreadHelper+0xc
1b msvcr71!_threadstartex+0x6f
1c kernel32!BaseThreadStart+0x37
Drew Bliss schrieb:
> So the only time it doesn’t work is when you use it with -c? Is your
> -c coming through? Do you see any attempt to execute your script?
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Albrecht
> Frenzel
> Sent: Wednesday, July 26, 2006 7:33 AM
> To: Kernel Debugging Interest List
> Subject: Re: [windbg] Executing .excr from a macro file fails to
> update the Calls Window
>
> When I execute a macro file containing .excr via WinDbg’s Command
> window, it works.
>
> My current -c macro file now only contains
> lm
> !analyze -v
>
> It gets executed.
>
> Albrecht
>
> Drew Bliss schrieb:
>
>>This works correctly for me so I’m not sure what’s going on. If you
>>execute the script manually in windbg instead of using -c does that
>>make a difference? When using -c are your macro commands actually
>>getting executed?
>>
>>-----Original Message-----
>>From: xxxxx@lists.osr.com
>>[mailto:xxxxx@lists.osr.com] On Behalf Of Albrecht
>>Frenzel
>>Sent: Sunday, July 23, 2006 7:20 AM
>>To: Kernel Debugging Interest List
>>Subject: [windbg] Executing .excr from a macro file fails to update
>>the Calls Window
>>
>>I’m using a macro file containig these commands to start mini dump
>>analysis:
>>
>> !analyze -v
>> ~#s
>> .excr
>>
>>The macro file is passed as -c parameter to WinDbg:
>>
>> -c $$<startup.mac>>>
>>After the macro file has executed, the Calls Window still contains the
>
>
>>stack frames of the dump code.
>>
>>After manually executing
>>
>> ~#s; .excr
>>
>>through WinDbg’s Command Window, the Calls Window doesn’t contain
>>these frames any more, as expected.
>>
>>It seems to me, that WinDbg fails to update the Calls Window, if .excr
>
>
>>gets executed from a macro file
>>
>>—
>>You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>—
>>You are currently subscribed to windbg as: unknown lmsubst tag
>
> argument: ‘’
>
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to windbg as: unknown lmsubst tag
argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com</startup.mac></d:>