Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Windows 64bit > BlueScreenOfDeath during vfw codec testing.

Reply
Thread Tools

BlueScreenOfDeath during vfw codec testing.

 
 
Skybuck Flying
Guest
Posts: n/a
 
      05-10-2010
Hello,

I was writing some crappy vfw codec code which I guess was wrong or
something and surprisingly it crashed/blue screened the system !

Which isn't supposed to happen is it ? (I was debugging the codec from
delphi's debugger via virtual dub and dll's attach to process I guess etc)

(Windows XP x64 Pro SP2 all patched up):

Text report from WinDBG... I shall upload the minidump as well so somebody
might examine it.

Link to minidump:

http://members.home.nl/hbthoupperman...i051010-01.dmp

"
Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\WINDOWS\Minidump\Mini051010-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is:
SRV*c:\Tools\WinDbg\WebSymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (2 procs) Free
x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 3790.srv03_sp2_gdr.100216-1301
Machine Name:
Kernel base = 0xfffff800`01000000 PsLoadedModuleList = 0xfffff800`011d4140
Debug session time: Mon May 10 17:40:10.171 2010 (GMT+2)
System Uptime: 0 days 9:03:49.104
Loading Kernel Symbols
.................................................. ..............
.................................................. ...............
..........................
Loading User Symbols
Loading unloaded module list
.................................................. .
************************************************** *****************************
*
*
* Bugcheck Analysis
*
*
*
************************************************** *****************************

Use !analyze -v to get detailed debugging information.

BugCheck 7F, {8, 80050031, 6f8, fffff800010554b7}

Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b8 )

Followup: MachineOwner
---------

0: kd> !analyze -v
************************************************** *****************************
*
*
* 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: 0000000080050031
Arg3: 00000000000006f8
Arg4: fffff800010554b7

Debugging Details:
------------------


BUGCHECK_STR: 0x7f_8

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: VirtualDub.exe

CURRENT_IRQL: 1

EXCEPTION_RECORD: fffffadfc65c19f0 -- (.exr 0xfffffadfc65c19f0)
ExceptionAddress: fffff8000104efca
(nt!RtlpUnwindPrologue+0x000000000000016b)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 00000000000000d1
Attempt to read from address 00000000000000d1

TRAP_FRAME: fffffadfc65c1a80 -- (.trap 0xfffffadfc65c1a80)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000004 rbx=0000000000000000 rcx=fffff8000104efb8
rdx=00000000000000d1 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8000104efca rsp=fffffadfc65c1c10 rbp=fffffadfc65c1d00
r8=0000000000000006 r9=fffff80001170f04 r10=0000000000000001
r11=fffffadfc65c1db0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!RtlpUnwindPrologue+0x16b:
fffff800`0104efca 488b02 mov rax,qword ptr [rdx]
ds:00000000`000000d1=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff8000102e5b4 to fffff8000102e890

STACK_TEXT:
fffff800`0007cce8 fffff800`0102e5b4 : 00000000`0000007f 00000000`00000008
00000000`80050031 00000000`000006f8 : nt!KeBugCheckEx
fffff800`0007ccf0 fffff800`0102ceb8 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x74
fffff800`0007ce70 fffff800`010554b7 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb8
fffffadf`c65c0c40 fffff800`0100b901 : fffffadf`c65c19f0 fffffadf`c65c1400
fffffadf`c65c19f0 fffffadf`c65c1a80 : nt!RtlDispatchException+0x37
fffffadf`c65c1300 fffff800`0102e6af : fffffadf`c65c19f0 00000000`00000000
fffffadf`c65c1a80 00000000`00000000 : nt!KiDispatchException+0xd9
fffffadf`c65c1900 fffff800`0102d521 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : nt!KiExceptionExit
fffffadf`c65c1a80 fffff800`0104efca : 00000000`00000000 00000000`00000001
fffff800`011eb678 fffff800`01000000 : nt!KiPageFault+0x1e1
fffffadf`c65c1c10 fffff800`0104a1d1 : fffff800`01027eb1 fffff800`0127f131
00000000`00000000 fffff800`012166ec : nt!RtlpUnwindPrologue+0x16b
fffffadf`c65c1c60 fffff800`01054a97 : 00000000`00000000 fffffadf`c65c6b90
00000000`00000000 00000000`c65c24a0 : nt!RtlVirtualUnwind+0x27b
fffffadf`c65c1ce0 00000000`00000000 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : nt!RtlDispatchException+0x10b


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KiDoubleFaultAbort+b8
fffff800`0102ceb8 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: 4b7abd06

FAILURE_BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b8

BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b8

Followup: MachineOwner
---------
"

Bye,
Skybuck.


 
Reply With Quote
 
 
 
 
Skybuck Flying
Guest
Posts: n/a
 
      05-10-2010
I tried to fix the codec a little bit, by setting the output size... but it
still crashed... maybe it's a delphi debugger conflict with a windows
patch... or maybe it's just the codec crashing... I will have to investigate
the algorithm in more detail sometime or so...

Anyway here is the second crash dump report and a link to the minidump:

http://members.home.nl/hbthoupperman...i051010-02.dmp

"
Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\WINDOWS\Minidump\Mini051010-02.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is:
SRV*c:\Tools\WinDbg\WebSymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (2 procs) Free
x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 3790.srv03_sp2_gdr.100216-1301
Machine Name:
Kernel base = 0xfffff800`01000000 PsLoadedModuleList = 0xfffff800`011d4140
Debug session time: Mon May 10 17:56:47.140 2010 (GMT+2)
System Uptime: 0 days 0:14:58.069
Loading Kernel Symbols
.................................................. ..............
.................................................. ...............
.........................
Loading User Symbols
Loading unloaded module list
.................................................. .
************************************************** *****************************
*
*
* Bugcheck Analysis
*
*
*
************************************************** *****************************

Use !analyze -v to get detailed debugging information.

BugCheck 7F, {8, 80050031, 6f8, fffff800010554b7}

Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b8 )

Followup: MachineOwner
---------

0: kd> !analyze -v
************************************************** *****************************
*
*
* 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: 0000000080050031
Arg3: 00000000000006f8
Arg4: fffff800010554b7

Debugging Details:
------------------


BUGCHECK_STR: 0x7f_8

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: VirtualDub.exe

CURRENT_IRQL: 1

EXCEPTION_RECORD: fffffadfc5d5aa30 -- (.exr 0xfffffadfc5d5aa30)
ExceptionAddress: fffff8000104efca
(nt!RtlpUnwindPrologue+0x000000000000016b)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 00000000000000d0
Attempt to read from address 00000000000000d0

TRAP_FRAME: fffffadfc5d5aac0 -- (.trap 0xfffffadfc5d5aac0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000004 rbx=0000000000000000 rcx=fffff8000104efb8
rdx=00000000000000d0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8000104efca rsp=fffffadfc5d5ac50 rbp=fffffadfc5d5ad00
r8=0000000000000006 r9=fffff80001170f04 r10=0000000000000001
r11=fffffadfc5d5adf0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!RtlpUnwindPrologue+0x16b:
fffff800`0104efca 488b02 mov rax,qword ptr [rdx]
ds:00000000`000000d0=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff8000102e5b4 to fffff8000102e890

STACK_TEXT:
fffff800`0007cce8 fffff800`0102e5b4 : 00000000`0000007f 00000000`00000008
00000000`80050031 00000000`000006f8 : nt!KeBugCheckEx
fffff800`0007ccf0 fffff800`0102ceb8 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x74
fffff800`0007ce70 fffff800`010554b7 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb8
fffffadf`c5d59c80 fffff800`0100b901 : fffffadf`c5d5aa30 fffffadf`c5d5a440
fffffadf`c5d5aa30 fffffadf`c5d5aac0 : nt!RtlDispatchException+0x37
fffffadf`c5d5a340 fffff800`0102e6af : fffffadf`c5d5aa30 00000000`00000000
fffffadf`c5d5aac0 00000000`00000000 : nt!KiDispatchException+0xd9
fffffadf`c5d5a940 fffff800`0102d521 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : nt!KiExceptionExit
fffffadf`c5d5aac0 fffff800`0104efca : 00000000`00000000 00000000`00000001
fffff800`011eb678 fffff800`01000000 : nt!KiPageFault+0x1e1
fffffadf`c5d5ac50 fffff800`0104a1d1 : fffff800`01027eb1 fffff800`01261a7f
00000000`00000000 fffff800`0120f9fc : nt!RtlpUnwindPrologue+0x16b
fffffadf`c5d5aca0 fffff800`01054a97 : 00000000`00000000 fffffadf`c5d5fae0
00000000`00000000 00000000`c5d5b4e0 : nt!RtlVirtualUnwind+0x27b
fffffadf`c5d5ad20 00000000`00000000 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : nt!RtlDispatchException+0x10b


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KiDoubleFaultAbort+b8
fffff800`0102ceb8 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: 4b7abd06

FAILURE_BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b8

BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b8

Followup: MachineOwner
---------
"

Bye,
Skybuck.


 
Reply With Quote
 
 
 
 
Skybuck Flying
Guest
Posts: n/a
 
      05-10-2010
I tested the code seperately from the codec code... and it's flawless as far
as I can tell.. therefore I no longer believe that the problem is actually
in my code... I could be wrong though.

To me it's starting to seem like an incompatibility between Delphi's 2007
debugger and the latest Windows XP x64 Pro Patches ?!?

The crash happens when Delphi 2007 debugger is paused and I press F8 to
continue debugging (on the last line of a routine?...) and boom... blue
screen of death results ?!

Bye,
Skybuck.


 
Reply With Quote
 
Doug Forster
Guest
Posts: n/a
 
      05-19-2010
I gave up trying to debug Delphi in Vista 64 because it just blue
screened at random. Replaced virtually every bit of hardware in the box
before deciding it was some OS incompatibility with the Delphi debugger.
So I went to Virtual PC in desperation.

But some time later I changed to Win7 64 and lo and behold the blue
screens stopped and all is sweet again.

Cheers
Doug Forster
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Codec lookup fails for bad codec name, blowing up BeautifulSoup John Nagle Python 3 11-10-2007 02:55 AM
video for windows (vfw) 64 bit drivers =?Utf-8?B?QQ==?= Windows 64bit 1 10-02-2007 09:40 PM
AVI Format using VFW Donovan Parks C++ 5 08-18-2007 06:28 PM
no vfw://0 in JMF CaptureDeviceManager getDeviceList ? jmfguy Java 1 07-30-2004 03:25 AM
VFW.h link error Helen C Programming 2 11-18-2003 02:45 AM



Advertisments