OSR's windbg List: Executing .excr from a macro file fails to update the Calls Window

Message 1 of 11

23 Jul 06 10:20

windbg member 30428

xxxxxx@nero.com

Join Date:

Posts To This List: 15

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

Message 2 of 11

24 Jul 06 13:48

windbg member 26440

xxxxxx@winse.microsoft.com

Join Date:

Posts To This List: 229

RE: Executing .excr from a macro file fails to update the Calls Window

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

Message 3 of 11

26 Jul 06 10:28

windbg member 30428

xxxxxx@nero.com

Join Date:

Posts To This List: 15

Re: 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 <...excess quoted lines suppressed...>

Message 4 of 11

26 Jul 06 10:33

windbg member 30428

xxxxxx@nero.com

Join Date:

Posts To This List: 15

Re: Executing .excr from a macro file fails to update the Calls Window

Message 5 of 11

26 Jul 06 13:38

windbg member 26440

xxxxxx@winse.microsoft.com

Join Date:

Posts To This List: 229

RE: Executing .excr from a macro file fails to update the Calls Window

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 <...excess quoted lines suppressed...> 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

Message 6 of 11

27 Jul 06 07:46

windbg member 30428

xxxxxx@nero.com

Join Date:

Posts To This List: 15

Re: 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:\test/Analyze.mac 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 <...excess quoted lines suppressed...>

Message 7 of 11

27 Jul 06 13:51

windbg member 26440

xxxxxx@winse.microsoft.com

Join Date:

Posts To This List: 229

RE: Executing .excr from a macro file fails to update the Calls Window

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: ==========================3D=========================3D==================== Content of Analyze.mac: lm !analyze -v ~9s .ecxr kb ==========================3D=========================3D==================== Macro file execution via -c option: 0:009> $$<D:\test/Analyze.mac 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 ==========================3D=========================3D=============== 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 <...excess quoted lines suppressed...> 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

Message 8 of 11

27 Jul 06 14:26

windbg member 30428

xxxxxx@nero.com

Join Date:

Posts To This List: 15

Re: Executing .excr from a macro file fails to update the Calls Window

The problem occures on WER mini dumps of optimized code w/o frame pointers. (I didn't test other code models.) Drew Bliss schrieb: > 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 > <...excess quoted lines suppressed...>

Message 9 of 11

27 Jul 06 14:47

windbg member 14841

xxxxxx@nero.com

Join Date:

Posts To This List: 23

RE: Executing .excr from a macro file fails to update the Calls Window

Hello Drew, May be it could be useful information - Albrecht is analyzing a user mode crash dump. I.e. internally script is processed by cdb but not by kd. Best regards, Oleksiy Shatylo > -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss > Sent: Thursday, July 27, 2006 7:51 PM > To: Kernel Debugging Interest List > Subject: RE: [windbg] Executing .excr from a macro file fails > to update the Calls Window > > I can't repro this, but I'll keep looking. <...excess quoted lines suppressed...>

Message 10 of 11

27 Jul 06 14:50

windbg member 26440

xxxxxx@winse.microsoft.com

Join Date:

Posts To This List: 229

RE: Executing .excr from a macro file fails to update the Calls Window

I'm assuming he's using windbg to look at the dump. Is that correct? If so it doesn't matter if it's a user or kernel dump. -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Oleksiy Shatylo Sent: Thursday, July 27, 2006 11:47 AM To: Kernel Debugging Interest List Subject: RE: [windbg] Executing .excr from a macro file fails to update the Calls Window Hello Drew, May be it could be useful information - Albrecht is analyzing a user mode crash dump. I.e. internally script is processed by cdb but not by kd. Best regards, Oleksiy Shatylo > -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss > Sent: Thursday, July 27, 2006 7:51 PM > To: Kernel Debugging Interest List > Subject: RE: [windbg] Executing .excr from a macro file fails to > update the Calls Window > > I can't repro this, but I'll keep looking. <...excess quoted lines suppressed...> --- You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To unsubscribe send a blank email to xxxxx@lists.osr.com

Message 11 of 11

27 Jul 06 15:45

windbg member 30428

xxxxxx@nero.com

Join Date:

Posts To This List: 15

Re: Executing .excr from a macro file fails to update the Calls Window

Yes, I'm using windbg 6.6.7.5 Drew Bliss schrieb: > I'm assuming he's using windbg to look at the dump. Is that correct? > If so it doesn't matter if it's a user or kernel dump. > > -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of Oleksiy Shatylo > Sent: Thursday, July 27, 2006 11:47 AM > To: Kernel Debugging Interest List > Subject: RE: [windbg] Executing .excr from a macro file fails to update > the Calls Window <...excess quoted lines suppressed...>

Posting Rules
You may not post new threads You may not post replies You may not post attachments	You must login to OSR Online AND be a member of the windbg list to be able to post.

All times are GMT -5. The time now is 03:28.

Contact Us - Osr Online Homepage - Top