1 Topic by mdl (edited by mdl 2011-10-12 12:43:17)

  • mdl
  • Banned
  • Offline
  • Registered: 2011-10-12
  • Posts: 8

Topic: Fireface 400 Windows 7 64-bit crashes

(This is a slightly modified version of the email that I just sent to RME support. I am posting it here to call attention to this issue. I kindly request that non-RME individuals with cargo cult "fixes" that do not solve the problem, such as changing PCI-E link state power management, changing the power scheme to "high performance", sacrificing a goat at midnight and bathing in its blood, etc., stay out of this thread, as the issue is NOT SPECIFIC to my system.)

(And, for the benefit of readers, as I have not attached my system configuration as I did in the support email--this is a MacPro1,1 running Windows 7 SP1 64-bit, with the magical fairy dust-sprinkled TI FireWire chip that's supposed to work just fine.)

This has been a long-standing issue for at LEAST two years, and honestly, it is completely unacceptable that it has still not been fixed.  There have been countless threads over the years on the RME forums about it, my old roommate had a Fireface 400 and saw the same problem on multiple systems, and it is still not fixed.

At the end of this post please find the output of !analyze -v from WinDbg clearly showing a crash within the Windows FireWire subsystem.

I have found a way to reliably reproduce this bug, and while it sounds ridiculous, experience debugging Windows software has taught me to not ignore seemingly-unrelated interactions--there was once a bug in a Windows DNS server product which triggered when Windows Media Player was also in use (had something to do with multimedia timers).

I have seen the issue no fewer than three times while:

1) foobar2000 (a music player) was playing, and;
2) Windows Installer was active.

This most recent crash, Windows Update was running.  During a previous crash, I was attempting to install VMware.  During a previous crash, I was installing some other product that used MSI.  I also experienced a crash once while working on a song in OpenMPT and installing some MSI thing in the background.

So, let us review:

1) The bugcheck happens in the FireWire subsystem;
2) The Fireface is the only thing on the FireWire bus;
3) Multiple client programs crash the machine, and;
4) The issue occurs across different systems with different FireWire controllers, leaving a single common element--the Fireface 400.

A fix to this is long overdue.  I look forward to seeing it resolved.

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


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

Symbol search path is: srv*C:\Windows\mdl_debugging_symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`02c5f000 PsLoadedModuleList = 0xfffff800`02ea4670
Debug session time: Wed Oct 12 01:39:45.953 2011 (UTC - 7:00)
System Uptime: 0 days 1:08:24.997
Loading Kernel Symbols
...............................................................
................................................................
...............................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {100000010329, 2, 0, fffff80002c1a806}

Probably caused by : 1394ohci.sys ( 1394ohci!IsochTx::Release+18d )

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

2: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000100000010329, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
    bit 0 : value 0 = read operation, 1 = write operation
    bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002c1a806, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002f0e100
 0000100000010329 

CURRENT_IRQL:  2

FAULTING_IP: 
hal!HalPutScatterGatherList+b6
fffff800`02c1a806 8b6f2c          mov     ebp,dword ptr [rdi+2Ch]

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  audiodg.exe

TRAP_FRAME:  fffff880061fc410 -- (.trap 0xfffff880061fc410)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000001
rdx=0000000000000fff rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002c1a806 rsp=fffff880061fc5a0 rbp=0000000000000900
 r8=fffffa800bc7b600  r9=0000000000000900 r10=0000000000000000
r11=fffff880061fc610 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
hal!HalPutScatterGatherList+0xb6:
fffff800`02c1a806 8b6f2c          mov     ebp,dword ptr [rdi+2Ch] ds:cce0:00000000`0000002c=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002cdb1e9 to fffff80002cdbc40

STACK_TEXT:  
fffff880`061fc2c8 fffff800`02cdb1e9 : 00000000`0000000a 00001000`00010329 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`061fc2d0 fffff800`02cd9e60 : 00000000`00000202 fffff800`02ce1fda fffff800`02e51e80 fffffa80`0931c1b0 : nt!KiBugCheckDispatch+0x69
fffff880`061fc410 fffff800`02c1a806 : fffffa80`0931c1b0 00000000`00000900 00000000`00000168 fffffa80`09e64490 : nt!KiPageFault+0x260
fffff880`061fc5a0 fffff880`00f10c65 : 00000000`00000000 00000000`00000000 fffffa80`092adcc8 fffffa80`092adc80 : hal!HalPutScatterGatherList+0xb6
fffff880`061fc600 fffff880`00f1029d : fffffa80`092adc60 00000000`00000000 fffffa80`092adcc8 00000000`00000005 : Wdf01000!FxDmaScatterGatherTransaction::ReleaseResources+0x39
fffff880`061fc630 fffff880`00f109fc : fffffa80`092adc60 00000000`00000000 fffffa80`092adc60 fffffa80`0931b200 : Wdf01000!FxDmaTransactionBase::Dispose+0xd1
fffff880`061fc680 fffff880`00f6dbb5 : fffffa80`092adc60 00000000`00000000 00000000`00000005 a87b86ac`72dabe50 : Wdf01000!FxDmaScatterGatherTransaction::Dispose+0x1c
fffff880`061fc6b0 fffff880`00f6d5c8 : fffffa80`092adc60 00000000`00000000 00000000`00000000 00000000`00000000 : Wdf01000!FxObject::DisposeChildrenWorker+0x215
fffff880`061fc730 fffff880`00f6d789 : fffffa80`092adc60 00000000`00000000 00000000`00000000 fffff800`02ce591a : Wdf01000!FxObject::PerformDisposingDisposeChildrenLocked+0xbc
fffff880`061fc7a0 fffff880`00f6db89 : fffffa80`0931b260 fffff880`00f3fe00 fffffa80`092adc60 fffffa80`0931b260 : Wdf01000!FxObject::PerformEarlyDisposeWorkerAndUnlock+0xf5
fffff880`061fc810 fffff880`00f6d883 : fffffa80`0931b260 00000000`00000000 00000000`00000000 fffffa80`0931b201 : Wdf01000!FxObject::DisposeChildrenWorker+0x1e9
fffff880`061fc890 fffff880`00f6d159 : fffffa80`0931b260 0000057f`f4e7d100 0000057f`f4e7d100 00000000`00000000 : Wdf01000!FxObject::DeleteWorkerAndUnlock+0xdf
fffff880`061fc8f0 fffff880`00f68085 : 0000057f`f6ce4d98 0000057f`f4e7d100 00000000`00000000 fffffa80`0a8e7e70 : Wdf01000!FxObject::DeleteObject+0x1a9
fffff880`061fc950 fffff880`0fd31645 : fffffa80`0931b260 fffffa80`0931b630 0000057f`f6ce4d98 0000057f`f6ce4d98 : Wdf01000!imp_WdfObjectDelete+0x101
fffff880`061fc9a0 fffff880`0fd29a5d : 00000000`00000000 0000057f`f4e7d188 fffffa80`0a994d90 fffffa80`0bfbf310 : 1394ohci!IsochTx::Release+0x18d
fffff880`061fca10 fffff880`0fd290a9 : 0000057f`f4e7d188 0000057f`f566b618 00000000`00000028 00000000`0022021d : 1394ohci!Isoch::HandleIsochFreeResources+0xe9
fffff880`061fca60 fffff880`00f54047 : fffffa80`0b182e70 fffffa80`0a8e7e70 fffffa80`0a8e7e70 fffff880`00f3eaab : 1394ohci!Isoch::WdfEvtIoInternalDeviceControl+0x161
fffff880`061fcad0 fffff880`00f5399f : fffffa80`0a9949e0 fffffa80`0b182e70 fffffa80`0a9949e0 fffffa80`0b182f00 : Wdf01000!FxIoQueue::DispatchRequestToDriver+0x56f
fffff880`061fcb50 fffff880`00f531ab : fffffa80`0a9949e0 00000000`00000000 00000000`00000000 00000000`00000000 : Wdf01000!FxIoQueue::DispatchEvents+0x4df
fffff880`061fcbc0 fffff880`00f51f1e : 00000000`00000000 fffffa80`0a9d48d0 fffffa80`0a9949e0 fffffa80`0b182f98 : Wdf01000!FxIoQueue::QueueRequestFromForward+0x1f7
fffff880`061fcc20 fffff880`00f52555 : 00000000`8517d300 00000000`00000000 fffffa80`0a9d48d0 fffff880`0fd456b8 : Wdf01000!FxIoQueue::ForwardRequestWorker+0x17a
fffff880`061fcc90 fffff880`00f2fcd6 : 00000000`0b297ba0 fffffa80`0a8e7e70 00000000`00000000 fffff880`0fd258c4 : Wdf01000!FxIoQueue::ForwardRequest+0x185
fffff880`061fcd00 fffff880`0fd258c4 : fffffa80`0a9949e0 0000057f`f4e7d188 fffffa80`0b182e70 fffffa80`0a9d4c80 : Wdf01000!imp_WdfRequestForwardToIoQueue+0x12e
fffff880`061fcd50 fffff880`0fd25605 : 0000057f`f4e7d188 0000057f`f562b728 00000000`00000028 fffffa80`0a9d4c80 : 1394ohci!Dispatch::DispatchIrbRequest+0xa8
fffff880`061fcda0 fffff880`00f54047 : fffffa80`0b182e70 fffffa80`0a8e7e70 fffffa80`0a8e7e70 fffff880`00f79f00 : 1394ohci!Dispatch::WdfEvtIoInternalDeviceControl+0x131
fffff880`061fce10 fffff880`00f5399f : fffffa80`0b182e70 fffffa80`0b182e70 fffffa80`0a9d48d0 fffffa80`0a9d48d0 : Wdf01000!FxIoQueue::DispatchRequestToDriver+0x56f
fffff880`061fce90 fffff880`00f52f98 : 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b182fc2 : Wdf01000!FxIoQueue::DispatchEvents+0x4df
fffff880`061fcf00 fffff880`00f58558 : fffffa80`0a187400 fffffa80`0b182e70 fffffa80`0a187390 fffffa80`0b182e70 : Wdf01000!FxIoQueue::QueueRequest+0x2bc
fffff880`061fcf70 fffff880`00f42245 : fffffa80`0b182e70 00000000`00000000 00000000`00000000 0000057f`f69edb68 : Wdf01000!FxPkgIo::Dispatch+0x37c
fffff880`061fcff0 fffff880`00f2e6d0 : 00000000`00000000 00000000`00000000 0000057f`f69edb68 fffff880`061fd0a0 : Wdf01000!FxDevice::Dispatch+0xa9
fffff880`061fd020 fffff880`0fd23178 : fffffa80`0a8e7fc0 fffffa80`09612490 fffffa80`0af53df0 fffffa80`0af5bfc0 : Wdf01000!imp_WdfRequestSend+0x37c
fffff880`061fd070 fffff880`0fd233af : fffffa80`0bfbf310 0000057f`f69edb68 0000057f`f69edb68 0000057f`f50a63a8 : 1394ohci!ChildDevice::DispatchIrbRequest+0x60
fffff880`061fd0c0 fffff880`0fd22289 : 0000057f`f69edb68 0000057f`f50a63a8 00000000`00000028 fffffa80`0af5bfc0 : 1394ohci!ChildDevice::HandleIrbRequest+0x1db
fffff880`061fd100 fffff880`00f54047 : fffffa80`09612490 fffffa80`0a8e7e70 fffffa80`0a8e7e70 fffff800`02ccf200 : 1394ohci!ChildDevice::WdfEvtIoInternalDeviceControl+0x141
fffff880`061fd170 fffff880`00f5399f : 00000000`00000000 fffffa80`09612490 fffffa80`0af59c50 fffffa80`0af59c50 : Wdf01000!FxIoQueue::DispatchRequestToDriver+0x56f
fffff880`061fd1f0 fffff880`00f52f98 : 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`096125e2 : Wdf01000!FxIoQueue::DispatchEvents+0x4df
fffff880`061fd260 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Wdf01000!FxIoQueue::QueueRequest+0x2bc


STACK_COMMAND:  kb

FOLLOWUP_IP: 
1394ohci!IsochTx::Release+18d
fffff880`0fd31645 488b0dc45a0100  mov     rcx,qword ptr [1394ohci!WPP_GLOBAL_Control (fffff880`0fd47110)]

SYMBOL_STACK_INDEX:  e

SYMBOL_NAME:  1394ohci!IsochTx::Release+18d

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: 1394ohci

IMAGE_NAME:  1394ohci.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4ce7a6a8

FAILURE_BUCKET_ID:  X64_0xA_1394ohci!IsochTx::Release+18d

BUCKET_ID:  X64_0xA_1394ohci!IsochTx::Release+18d

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

2 Reply by MC

  • MC
  • MC
  • Administrator
  • Offline
  • From: Germany/Thailand
  • Registered: 2007-04-06
  • Posts: 25,600

Re: Fireface 400 Windows 7 64-bit crashes

> I have found a way to reliably reproduce this bug

We are always interested to hear such things, but it seems I missed it - where did you describe how to reliably crash it?

Regards
Matthias Carstens
RME

MC's Website

3 Reply by mdl (edited by mdl 2011-10-12 12:26:05)

  • mdl
  • Banned
  • Offline
  • Registered: 2011-10-12
  • Posts: 8

Re: Fireface 400 Windows 7 64-bit crashes

MC wrote:

> I have found a way to reliably reproduce this bug

We are always interested to hear such things, but it seems I missed it - where did you describe how to reliably crash it?

The important variables seem to be:

1) sound is playing (it doesn't seem to matter with what--foobar2000 was using waveout/DirectSound, OpenMPT was using ASIO);
2) an MSI/Windows Installer activity is running.

Remember: the crash happens in the FireWire subsystem, and the Fireface is the only thing on the FireWire bus. I do not believe #2 is the cause of the issue; it simply seems to exacerbate it.

4 Reply by MC

  • MC
  • MC
  • Administrator
  • Offline
  • From: Germany/Thailand
  • Registered: 2007-04-06
  • Posts: 25,600

Re: Fireface 400 Windows 7 64-bit crashes

That is an interesting point. I usually do not have music runing in the background while I install programs, but am sure that I did that too. It would be helpful if you could remember the program that used the MSI installer. Trying to check this will take some time, but we will do so.

Regards
Matthias Carstens
RME

MC's Website

5 Reply by mdl (edited by mdl 2011-10-12 17:54:08)

  • mdl
  • Banned
  • Offline
  • Registered: 2011-10-12
  • Posts: 8

Re: Fireface 400 Windows 7 64-bit crashes

The crash that resulted in the previous dump was while running Windows Update. I have noticed that when install or uninstall processes begin, the audio starts to skip or sound as if the last samples in the buffer are being played in a loop, and the system usually then crashes shortly thereafter--in the aforementioned case, it happened almost immediately. Judging from some of the other crashes mentioned in the first post, it seems that the more time spent in whatever call(s) the installer makes prior to beginning an install or uninstall operation, the more likely the system is to crash. This sounds ridiculous, but then, so did the multimedia timer interaction I mentioned in the first post until I witnessed it myself. Windows is a nightmare.

I attempted to reproduce the issue by installing and uninstalling Python 2.7.2 32-bit repeatedly, and eventually succeeded. The audio skipped at the beginning of each install/uninstall, but did not immediately crash as in the previous case. However, the skipping always precipitates a crash. I took a break, and when I came back, I found the machine had crashed. The dump follows--notice the call into the kernel with the bogus pointer coming from audiodg.exe:

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


Loading Dump File [C:\Users\mdl\Desktop\101211-39951-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: srv*C:\Windows\mdl_debugging_symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`02c1b000 PsLoadedModuleList = 0xfffff800`02e60670
Debug session time: Wed Oct 12 05:01:31.837 2011 (UTC - 7:00)
System Uptime: 0 days 1:29:05.491
Loading Kernel Symbols
...............................................................
................................................................
...............................
Loading User Symbols
Loading unloaded module list
......
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 3B, {c0000005, fffff80002c9ec0e, fffff880091c4df0, 0}

Probably caused by : ntkrnlmp.exe ( nt!KiSignalSynchronizationObject+4e )

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

3: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff80002c9ec0e, Address of the instruction which caused the bugcheck
Arg3: fffff880091c4df0, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

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


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP: 
nt!KiSignalSynchronizationObject+4e
fffff800`02c9ec0e 488908          mov     qword ptr [rax],rcx

CONTEXT:  fffff880091c4df0 -- (.cxr 0xfffff880091c4df0)
rax=850fe48445ffffff rbx=fffff880091c58b8 rcx=59840fc00000163d
rdx=fffff880091c58b0 rsi=fffff880091c58b0 rdi=59840fc00000163d
rip=fffff80002c9ec0e rsp=fffff880091c57d0 rbp=0000000000000002
 r8=0000000000000000  r9=00000000c0000005 r10=fffff880091c5980
r11=fffff880091c59a8 r12=fffff80002c9b021 r13=fffff880009aa180
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz ac po cy
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010297
nt!KiSignalSynchronizationObject+0x4e:
fffff800`02c9ec0e 488908          mov     qword ptr [rax],rcx ds:002b:850fe484`45ffffff=????????????????
Resetting default scope

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x3B

PROCESS_NAME:  audiodg.exe

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from 0000000000000000 to fffff80002c9ec0e

STACK_TEXT:  
fffff880`091c57d0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSignalSynchronizationObject+0x4e


FOLLOWUP_IP: 
nt!KiSignalSynchronizationObject+4e
fffff800`02c9ec0e 488908          mov     qword ptr [rax],rcx

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nt!KiSignalSynchronizationObject+4e

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4e02aaa3

STACK_COMMAND:  .cxr 0xfffff880091c4df0 ; kb

FAILURE_BUCKET_ID:  X64_0x3B_nt!KiSignalSynchronizationObject+4e

BUCKET_ID:  X64_0x3B_nt!KiSignalSynchronizationObject+4e

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

6 Reply by November (edited by November 2011-10-12 19:27:37)

  • Registered: 2010-01-19
  • Posts: 25

Re: Fireface 400 Windows 7 64-bit crashes

For the record, I am mdl's roommate in question. Please see this thread for my own experience with the Fireface 400 under Windows 7 with the same results. This is pretty sad that it's been almost two years and this issue hasn't been resolved. I've since moved onto other hardware.

  • From: Germany
  • Registered: 2007-04-10
  • Posts: 9,782

Re: Fireface 400 Windows 7 64-bit crashes

If there had been an unfixed issue for two years, with people experiencing regular crashes, the forum (and my mailbox) would be full of it. That is not the case, though. That is not to say there isn't something in the specific circumstances outlined above, which we wiil look into.


Regards
Daniel Fuchs
RME

Regards
Daniel Fuchs
RME

RME Support's Website

  • mdl
  • Banned
  • Offline
  • Registered: 2011-10-12
  • Posts: 8

Re: Fireface 400 Windows 7 64-bit crashes

Two more crashes, the second one on the latest driver, and still the same issue...

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


Loading Dump File [C:\Users\mdl\Desktop\crash3\101511-30919-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: srv*C:\Windows\mdl_debugging_symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`02e1a000 PsLoadedModuleList = 0xfffff800`0305f670
Debug session time: Sat Oct 15 12:30:01.822 2011 (UTC - 7:00)
System Uptime: 0 days 0:19:48.476
Loading Kernel Symbols
...............................................................
................................................................
................................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {400733, 2, 0, fffff80003407806}

Probably caused by : 1394ohci.sys ( 1394ohci!IsochTx::Release+18d )

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

2: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000400733, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
    bit 0 : value 0 = read operation, 1 = write operation
    bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80003407806, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800030c9100
 0000000000400733 

CURRENT_IRQL:  2

FAULTING_IP: 
hal!HalPutScatterGatherList+b6
fffff800`03407806 8b6f2c          mov     ebp,dword ptr [rdi+2Ch]

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  audiodg.exe

TRAP_FRAME:  fffff88008c90410 -- (.trap 0xfffff88008c90410)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000001
rdx=0000000000000fff rsi=0000000000000000 rdi=0000000000000000
rip=fffff80003407806 rsp=fffff88008c905a0 rbp=0000000000000360
 r8=fffffa8009493040  r9=0000000000000360 r10=0000000000000000
r11=fffff88008c90610 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
hal!HalPutScatterGatherList+0xb6:
fffff800`03407806 8b6f2c          mov     ebp,dword ptr [rdi+2Ch] ds:ece0:00000000`0000002c=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002e961e9 to fffff80002e96c40

STACK_TEXT:  
fffff880`08c902c8 fffff800`02e961e9 : 00000000`0000000a 00000000`00400733 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`08c902d0 fffff800`02e94e60 : 00000000`00000202 fffff800`02e9cfda fffff800`0300ce80 fffffa80`0947e7d0 : nt!KiBugCheckDispatch+0x69
fffff880`08c90410 fffff800`03407806 : fffffa80`0947e7d0 00000000`00000360 00000000`000001b0 fffffa80`0c71ae70 : nt!KiPageFault+0x260
fffff880`08c905a0 fffff880`00e73c65 : 00000000`00000000 00000000`00000000 fffffa80`0947e8f8 fffffa80`0947e8b0 : hal!HalPutScatterGatherList+0xb6
fffff880`08c90600 fffff880`00e7329d : fffffa80`0947e890 00000000`00000000 fffffa80`0947e8f8 00000000`00000200 : Wdf01000!FxDmaScatterGatherTransaction::ReleaseResources+0x39
fffff880`08c90630 fffff880`00e739fc : fffffa80`0947e890 00000000`00000000 fffffa80`0947e890 fffff6fb`7ea00200 : Wdf01000!FxDmaTransactionBase::Dispose+0xd1
fffff880`08c90680 fffff880`00ed0bb5 : fffffa80`0947e890 00000000`00000000 00000000`00000005 fffff800`0342fc60 : Wdf01000!FxDmaScatterGatherTransaction::Dispose+0x1c
fffff880`08c906b0 fffff880`00ed05c8 : fffffa80`0947e890 00000000`00000000 00000000`00000000 fffff880`00ed0a00 : Wdf01000!FxObject::DisposeChildrenWorker+0x215
fffff880`08c90730 fffff880`00ed0789 : fffffa80`0947e890 00000000`00000000 00000000`00000000 fffffa80`090020c0 : Wdf01000!FxObject::PerformDisposingDisposeChildrenLocked+0xbc
fffff880`08c907a0 fffff880`00ed0b89 : fffffa80`093ee020 fffff880`00ea2e00 fffffa80`0947e890 fffffa80`093ee020 : Wdf01000!FxObject::PerformEarlyDisposeWorkerAndUnlock+0xf5
fffff880`08c90810 fffff880`00ed0883 : fffffa80`093ee020 00000000`00000000 00000000`00000000 fffffa80`093ee001 : Wdf01000!FxObject::DisposeChildrenWorker+0x1e9
fffff880`08c90890 fffff880`00ed0159 : fffffa80`093ee020 0000057f`f6b78600 0000057f`f6b78600 00000000`00000000 : Wdf01000!FxObject::DeleteWorkerAndUnlock+0xdf
fffff880`08c908f0 fffff880`00ecb085 : 0000057f`f6c11fd8 0000057f`f6b78688 00000000`00000000 fffffa80`0a7f7270 : Wdf01000!FxObject::DeleteObject+0x1a9
fffff880`08c90950 fffff880`0fd52645 : fffffa80`093ee020 fffffa80`093ed2c0 0000057f`f6c11fd8 0000057f`f6c11fd8 : Wdf01000!imp_WdfObjectDelete+0x101
fffff880`08c909a0 fffff880`0fd4aa5d : 00000000`00000000 0000057f`f6b78688 fffffa80`0a864640 fffffa80`09ce9810 : 1394ohci!IsochTx::Release+0x18d
fffff880`08c90a10 fffff880`0fd4a0a9 : 0000057f`f6b78688 0000057f`f579bd68 00000000`00000028 00000000`0022021d : 1394ohci!Isoch::HandleIsochFreeResources+0xe9
fffff880`08c90a60 fffff880`00eb7047 : fffffa80`09487970 fffffa80`0a7f7270 fffffa80`0a7f7270 fffff880`00ea1aab : 1394ohci!Isoch::WdfEvtIoInternalDeviceControl+0x161
fffff880`08c90ad0 fffff880`00eb699f : fffffa80`0a864290 fffffa80`09487970 fffffa80`0a864290 fffffa80`09487a00 : Wdf01000!FxIoQueue::DispatchRequestToDriver+0x56f
fffff880`08c90b50 fffff880`00eb61ab : fffffa80`0a864290 00000000`00000000 00000000`00000000 00000000`00000000 : Wdf01000!FxIoQueue::DispatchEvents+0x4df
fffff880`08c90bc0 fffff880`00eb4f1e : 00000000`00000000 fffffa80`0a8648d0 fffffa80`0a864290 fffffa80`09487a98 : Wdf01000!FxIoQueue::QueueRequestFromForward+0x1f7
fffff880`08c90c20 fffff880`00eb5555 : 00000000`8517d300 00000000`00000000 fffffa80`0a8648d0 fffff880`0fd666b8 : Wdf01000!FxIoQueue::ForwardRequestWorker+0x17a
fffff880`08c90c90 fffff880`00e92cd6 : 00000000`0b378670 fffffa80`0a7f7270 00000000`00000000 fffff880`0fd468c4 : Wdf01000!FxIoQueue::ForwardRequest+0x185
fffff880`08c90d00 fffff880`0fd468c4 : fffffa80`0a864290 0000057f`f6b78688 fffffa80`09487970 fffffa80`0a864c80 : Wdf01000!imp_WdfRequestForwardToIoQueue+0x12e
fffff880`08c90d50 fffff880`0fd46605 : 0000057f`f6b78688 0000057f`f579b728 00000000`00000028 fffffa80`0a864c80 : 1394ohci!Dispatch::DispatchIrbRequest+0xa8
fffff880`08c90da0 fffff880`00eb7047 : fffffa80`09487970 fffffa80`0a7f7270 fffffa80`0a7f7270 fffff880`00edcf00 : 1394ohci!Dispatch::WdfEvtIoInternalDeviceControl+0x131
fffff880`08c90e10 fffff880`00eb699f : fffffa80`09487970 fffffa80`09487970 fffffa80`0a8648d0 fffffa80`0a8648d0 : Wdf01000!FxIoQueue::DispatchRequestToDriver+0x56f
fffff880`08c90e90 fffff880`00eb5f98 : 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`09487ac2 : Wdf01000!FxIoQueue::DispatchEvents+0x4df
fffff880`08c90f00 fffff880`00ebb558 : fffffa80`09871500 fffffa80`09487970 fffffa80`098713d0 fffffa80`09487970 : Wdf01000!FxIoQueue::QueueRequest+0x2bc
fffff880`08c90f70 fffff880`00ea5245 : fffffa80`09487970 00000000`00000000 00000000`00000000 0000057f`f4f62188 : Wdf01000!FxPkgIo::Dispatch+0x37c
fffff880`08c90ff0 fffff880`00e916d0 : 00000000`00000000 00000000`00000000 0000057f`f4f62188 fffff880`08c910a0 : Wdf01000!FxDevice::Dispatch+0xa9
fffff880`08c91020 fffff880`0fd44178 : fffffa80`0a7f73c0 fffffa80`0b09de70 fffffa80`0b078c20 fffffa80`0b082fc0 : Wdf01000!imp_WdfRequestSend+0x37c
fffff880`08c91070 fffff880`0fd443af : fffffa80`09ce9810 0000057f`f4f62188 0000057f`f4f62188 0000057f`f4f7f3a8 : 1394ohci!ChildDevice::DispatchIrbRequest+0x60
fffff880`08c910c0 fffff880`0fd43289 : 0000057f`f4f62188 0000057f`f4f7f3a8 00000000`00000028 fffffa80`0b082fc0 : 1394ohci!ChildDevice::HandleIrbRequest+0x1db
fffff880`08c91100 fffff880`00eb7047 : fffffa80`0b09de70 fffffa80`0a7f7270 fffffa80`0a7f7270 fffff800`02e8a200 : 1394ohci!ChildDevice::WdfEvtIoInternalDeviceControl+0x141
fffff880`08c91170 fffff880`00eb699f : 00000000`00000000 fffffa80`0b09de70 fffffa80`0b080c50 fffffa80`0b080c50 : Wdf01000!FxIoQueue::DispatchRequestToDriver+0x56f
fffff880`08c911f0 fffff880`00eb5f98 : 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b09dfc2 : Wdf01000!FxIoQueue::DispatchEvents+0x4df
fffff880`08c91260 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Wdf01000!FxIoQueue::QueueRequest+0x2bc


STACK_COMMAND:  kb

FOLLOWUP_IP: 
1394ohci!IsochTx::Release+18d
fffff880`0fd52645 488b0dc45a0100  mov     rcx,qword ptr [1394ohci!WPP_GLOBAL_Control (fffff880`0fd68110)]

SYMBOL_STACK_INDEX:  e

SYMBOL_NAME:  1394ohci!IsochTx::Release+18d

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: 1394ohci

IMAGE_NAME:  1394ohci.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4ce7a6a8

FAILURE_BUCKET_ID:  X64_0xA_1394ohci!IsochTx::Release+18d

BUCKET_ID:  X64_0xA_1394ohci!IsochTx::Release+18d

Followup: MachineOwner
---------
Loading Dump File [C:\Users\mdl\Desktop\crash4\101511-93772-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: srv*C:\Windows\mdl_debugging_symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`02e5e000 PsLoadedModuleList = 0xfffff800`030a3670
Debug session time: Sat Oct 15 13:19:08.360 2011 (UTC - 7:00)
System Uptime: 0 days 0:39:33.030
Loading Kernel Symbols
...............................................................
................................................................
...............................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {6002d, 2, 0, fffff80002e19806}

Probably caused by : 1394ohci.sys ( 1394ohci!IsochTx::Release+18d )

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

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 000000000006002d, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
    bit 0 : value 0 = read operation, 1 = write operation
    bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002e19806, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff8000310d100
 000000000006002d 

CURRENT_IRQL:  2

FAULTING_IP: 
hal!HalPutScatterGatherList+b6
fffff800`02e19806 8b6f2c          mov     ebp,dword ptr [rdi+2Ch]

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  audiodg.exe

TRAP_FRAME:  fffff88007288410 -- (.trap 0xfffff88007288410)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000001
rdx=0000000000000fff rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002e19806 rsp=fffff880072885a0 rbp=0000000000000168
 r8=fffffa8009821200  r9=0000000000000168 r10=0000000000000000
r11=fffff88007288610 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
hal!HalPutScatterGatherList+0xb6:
fffff800`02e19806 8b6f2c          mov     ebp,dword ptr [rdi+2Ch] ds:d340:00000000`0000002c=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002eda1e9 to fffff80002edac40

STACK_TEXT:  
fffff880`072882c8 fffff800`02eda1e9 : 00000000`0000000a 00000000`0006002d 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`072882d0 fffff800`02ed8e60 : 00000000`00000202 fffff800`02ee0fda fffff880`03115180 fffffa80`097de1a0 : nt!KiBugCheckDispatch+0x69
fffff880`07288410 fffff800`02e19806 : fffffa80`097de1a0 00000000`00000168 00000000`00000168 fffffa80`0a5192e0 : nt!KiPageFault+0x260
fffff880`072885a0 fffff880`00e4fc65 : 00000000`00000000 00000000`00000000 fffffa80`097de2c8 fffffa80`097de280 : hal!HalPutScatterGatherList+0xb6
fffff880`07288600 fffff880`00e4f29d : fffffa80`097de260 00000000`00000000 fffffa80`097de2c8 00000000`00000200 : Wdf01000!FxDmaScatterGatherTransaction::ReleaseResources+0x39
fffff880`07288630 fffff880`00e4f9fc : fffffa80`097de260 00000000`00000000 fffffa80`097de260 fffff6fb`7ea00200 : Wdf01000!FxDmaTransactionBase::Dispose+0xd1
fffff880`07288680 fffff880`00eacbb5 : fffffa80`097de260 00000000`00000000 00000000`00000005 00000000`00000000 : Wdf01000!FxDmaScatterGatherTransaction::Dispose+0x1c
fffff880`072886b0 fffff880`00eac5c8 : fffffa80`097de260 00000000`00000000 00000000`00000000 fffff880`00eaca00 : Wdf01000!FxObject::DisposeChildrenWorker+0x215
fffff880`07288730 fffff880`00eac789 : fffffa80`097de260 00000000`00000000 00000000`00000000 fffffa80`09002180 : Wdf01000!FxObject::PerformDisposingDisposeChildrenLocked+0xbc
fffff880`072887a0 fffff880`00eacb89 : fffffa80`0975d680 fffff880`00e7ee00 fffffa80`097de260 fffffa80`0975d680 : Wdf01000!FxObject::PerformEarlyDisposeWorkerAndUnlock+0xf5
fffff880`07288810 fffff880`00eac883 : fffffa80`0975d680 00000000`00000000 00000000`00000000 fffffa80`0975d601 : Wdf01000!FxObject::DisposeChildrenWorker+0x1e9
fffff880`07288890 fffff880`00eac159 : fffffa80`0975d680 0000057f`f665e100 0000057f`f665e100 00000000`00000000 : Wdf01000!FxObject::DeleteWorkerAndUnlock+0xdf
fffff880`072888f0 fffff880`00ea7085 : 0000057f`f68a2978 0000057f`f665e188 00000000`00000000 fffffa80`0a7e8010 : Wdf01000!FxObject::DeleteObject+0x1a9
fffff880`07288950 fffff880`044fa645 : fffffa80`0975d680 fffffa80`0975da50 0000057f`f68a2978 0000057f`f68a2978 : Wdf01000!imp_WdfObjectDelete+0x101
fffff880`072889a0 fffff880`044f2a5d : 00000000`00000000 0000057f`f665e188 fffffa80`0a7c5890 fffffa80`09e16d60 : 1394ohci!IsochTx::Release+0x18d
fffff880`07288a10 fffff880`044f20a9 : 0000057f`f665e188 0000057f`f583ab18 00000000`00000028 00000000`0022021d : 1394ohci!Isoch::HandleIsochFreeResources+0xe9
fffff880`07288a60 fffff880`00e93047 : fffffa80`099a1e70 fffffa80`0a7e8010 fffffa80`0a7e8010 fffff880`00e7daab : 1394ohci!Isoch::WdfEvtIoInternalDeviceControl+0x161
fffff880`07288ad0 fffff880`00e9299f : fffffa80`0a7c54e0 fffffa80`099a1e70 fffffa80`0a7c54e0 fffffa80`099a1f00 : Wdf01000!FxIoQueue::DispatchRequestToDriver+0x56f
fffff880`07288b50 fffff880`00e921ab : fffffa80`0a7c54e0 00000000`00000000 00000000`00000000 00000000`00000000 : Wdf01000!FxIoQueue::DispatchEvents+0x4df
fffff880`07288bc0 fffff880`00e90f1e : 00000000`00000000 fffffa80`0a7c4020 fffffa80`0a7c54e0 fffffa80`099a1f98 : Wdf01000!FxIoQueue::QueueRequestFromForward+0x1f7
fffff880`07288c20 fffff880`00e91555 : 00000000`8517d300 00000000`00000000 fffffa80`0a7c4020 fffff880`0450e6b8 : Wdf01000!FxIoQueue::ForwardRequestWorker+0x17a
fffff880`07288c90 fffff880`00e6ecd6 : 00000000`0b38e0d0 fffffa80`0a7e8010 00000000`00000000 fffff880`044ee8c4 : Wdf01000!FxIoQueue::ForwardRequest+0x185
fffff880`07288d00 fffff880`044ee8c4 : fffffa80`0a7c54e0 0000057f`f665e188 fffffa80`099a1e70 fffffa80`0a7c43d0 : Wdf01000!imp_WdfRequestForwardToIoQueue+0x12e
fffff880`07288d50 fffff880`044ee605 : 0000057f`f665e188 0000057f`f583bfd8 00000000`00000028 fffffa80`0a7c43d0 : 1394ohci!Dispatch::DispatchIrbRequest+0xa8
fffff880`07288da0 fffff880`00e93047 : fffffa80`099a1e70 fffffa80`0a7e8010 fffffa80`0a7e8010 fffff880`00eb8f00 : 1394ohci!Dispatch::WdfEvtIoInternalDeviceControl+0x131
fffff880`07288e10 fffff880`00e9299f : fffffa80`099a1e70 fffffa80`099a1e70 fffffa80`0a7c4020 fffffa80`0a7c4020 : Wdf01000!FxIoQueue::DispatchRequestToDriver+0x56f
fffff880`07288e90 fffff880`00e91f98 : 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`099a1fc2 : Wdf01000!FxIoQueue::DispatchEvents+0x4df
fffff880`07288f00 fffff880`00e97558 : fffffa80`09343100 fffffa80`099a1e70 fffffa80`09343010 fffffa80`099a1e70 : Wdf01000!FxIoQueue::QueueRequest+0x2bc
fffff880`07288f70 fffff880`00e81245 : fffffa80`099a1e70 00000000`00000000 00000000`00000000 0000057f`f3c09188 : Wdf01000!FxPkgIo::Dispatch+0x37c
fffff880`07288ff0 fffff880`00e6d6d0 : 00000000`00000000 00000000`00000000 0000057f`f3c09188 fffff880`072890a0 : Wdf01000!FxDevice::Dispatch+0xa9
fffff880`07289020 fffff880`044ec178 : fffffa80`0a7e8160 fffffa80`0c3f6e70 fffffa80`0af90020 fffffa80`0afbafc0 : Wdf01000!imp_WdfRequestSend+0x37c
fffff880`07289070 fffff880`044ec3af : fffffa80`09e16d60 0000057f`f3c09188 0000057f`f3c09188 0000057f`f5054fd8 : 1394ohci!ChildDevice::DispatchIrbRequest+0x60
fffff880`072890c0 fffff880`044eb289 : 0000057f`f3c09188 0000057f`f5054fd8 00000000`00000028 fffffa80`0afbafc0 : 1394ohci!ChildDevice::HandleIrbRequest+0x1db
fffff880`07289100 fffff880`00e93047 : fffffa80`0c3f6e70 fffffa80`0a7e8010 fffffa80`0a7e8010 fffff800`02ece200 : 1394ohci!ChildDevice::WdfEvtIoInternalDeviceControl+0x141
fffff880`07289170 fffff880`00e9299f : 00000000`00000000 fffffa80`0c3f6e70 fffffa80`0afab020 fffffa80`0afab020 : Wdf01000!FxIoQueue::DispatchRequestToDriver+0x56f
fffff880`072891f0 fffff880`00e91f98 : 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0c3f6fc2 : Wdf01000!FxIoQueue::DispatchEvents+0x4df
fffff880`07289260 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Wdf01000!FxIoQueue::QueueRequest+0x2bc


STACK_COMMAND:  kb

FOLLOWUP_IP: 
1394ohci!IsochTx::Release+18d
fffff880`044fa645 488b0dc45a0100  mov     rcx,qword ptr [1394ohci!WPP_GLOBAL_Control (fffff880`04510110)]

SYMBOL_STACK_INDEX:  e

SYMBOL_NAME:  1394ohci!IsochTx::Release+18d

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: 1394ohci

IMAGE_NAME:  1394ohci.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4ce7a6a8

FAILURE_BUCKET_ID:  X64_0xA_1394ohci!IsochTx::Release+18d

BUCKET_ID:  X64_0xA_1394ohci!IsochTx::Release+18d

Followup: MachineOwner
---------
  • mdl
  • Banned
  • Offline
  • Registered: 2011-10-12
  • Posts: 8

Re: Fireface 400 Windows 7 64-bit crashes

Any updates on this?

  • Registered: 2008-01-01
  • Posts: 3,025

Re: Fireface 400 Windows 7 64-bit crashes

Does this happen when the FF is *not* the default playback device while you choose to output sound to via via the application. Does it happen when you specifically "Disable all Enhancements" via Windows' Sound settings?

I kindly request that non-RME individuals with cargo cult "fixes" that do not solve the problem, such as changing PCI-E link state power management, changing the power scheme to "high performance", sacrificing a goat at midnight and bathing in its blood, etc., stay out of this thread, as the issue is NOT SPECIFIC to my system.

On the other hand I was specifically asked to stay out of this thread, so maybe I should just lean back and watch. (PS: the "cargo cult fixes" solve reproducible BSOD here that happen in far less esoteric situations that yours). HeadScratch

  • Jeff
  • Jeff
  • Moderator
  • Offline
  • From: USA
  • Registered: 2007-05-21
  • Posts: 4,667

Re: Fireface 400 Windows 7 64-bit crashes

Timur is right, using High Performance for Power Scheme is no magical thinking, this solves a lot of odd problems in Win 7. I can't say it applies here, but it does not hurt anything. Also, using the (Legacy) FireWire driver provides measurably better performance than the buggy Win 7 default driver, and fixes detection / crash issues. If you have not done so, make sure this is used even for your TI chipset.

http://www.rme-audio.de/forum/viewtopic.php?id=9827

Obviously, PCIe power management stuff does not apply here, and even if you had a PCIe FW card, the Mac Pro has no BIOS to change that particular setting.

Regards,
Jeff Petersen
Synthax Inc.

Jeff's Website

  • Registered: 2008-01-01
  • Posts: 3,025

Re: Fireface 400 Windows 7 64-bit crashes

I think MDL means that he already tried to turn off "PCI Express -> Link State Power Management" in Windows' power profile (which is "off" by default in the "High Performance" profile, but on in the other profiles). This particular setting cures reproducible BSOD on my bootcamped (W7 64-bit) Macbook Pro when using the FF400.

13 Reply by rwil (edited by rwil 2011-11-04 20:54:23)

  • rwil
  • rwil
  • S/Mux specialist
  • Offline
  • From: Montreal
  • Registered: 2007-05-01
  • Posts: 343

Re: Fireface 400 Windows 7 64-bit crashes

Out of curiosity I started MediaPlayer to play music using DS (adat 7-8), iTunes to play a video using DS (adat 7-8), and also foobar to play a track using ASIO (an 1-2). They played all together while I used Windows Update to perform the latest Office 2010 SP 350mo update, and all played fine during all the update process, nothing special and even not a single glitche! I was even having my regular power profile using Aero, not the one that I use for music only purpose.
Priority is on background services and of course no sound system enabled, otherwise usual things around pci irq etc...
I can't see if the FF400 is the culprit, why I never got that problem?

Asus P8Z77-V LE Plus_i7-3770K-3.9GHz_DDR3-16GB_Win8.1-x64_TI FW PCI_1xUAD-2_Cubase 4&7

14 Reply by mdl (edited by mdl 2012-03-03 02:11:11)

  • mdl
  • Banned
  • Offline
  • Registered: 2011-10-12
  • Posts: 8

Re: Fireface 400 Windows 7 64-bit crashes

I now have a Fireface UFX. I didn't need to upgrade, but I wanted to see if it fixed the issue. Well, it doesn't. The exact same bug exists. Plug the thing in via FireWire, install or uninstall an MSI while sound is playing, and you get skipping. When the program closes the sound device, the system will usually crash. Over USB, it still skips, but I haven't made the machine crash (yet).

Is this ever going to be fixed?

All you need to do to reproduce this: get an Intel Mac, install Windows 7 64-bit SP1, and:

1) run foobar2000, have it make noise;
2) install/uninstall an MSI (I've been using Python 2.6.2 32-bit to test, but it shouldn't matter)--this is when you will get skipping;
3) hit stop in foobar2000--if it doesn't crash, try it again; don't worry, it eventually will.

  • Registered: 2008-01-01
  • Posts: 3,025

Re: Fireface 400 Windows 7 64-bit crashes

Sorry MDL, but this seems to be an issue of your specific setup. Running Foobar2000 1.1.11 while using the Python 2.6.2 MSI installer (both 32 and 64 bit) on bootcamped Windows 7 64-bit (Ultimate) neither results in skipping nor crashing for me. Running on an early 2011 Macbook Pro.

Since my FF400 is connected via a Lindy repeater cable I will try the same with an UFX and direct cabling, but doubt that it will lead to a different outcome.

16 Reply by Timur Born (edited by Timur Born 2012-03-05 11:37:06)

  • Registered: 2008-01-01
  • Posts: 3,025

Re: Fireface 400 Windows 7 64-bit crashes

Same result with the UFX. I even deliberately turned on PCI Express -> Link State Power Management in order to push for troubles, but everything works.

I am currently on driver version 3.067 and using the _non_ legacy OHCI driver (aka new one in W7).

Are you using any special plugins in Foobar, like ASIO playback or something?

  • Registered: 2008-01-01
  • Posts: 3,025

Re: Fireface 400 Windows 7 64-bit crashes

Tried the Foorbar ASIO plugin via UFX with FF settings at 64 and 48 samples and everything seems to work.

18 Reply by gamerx (edited by gamerx 2012-03-05 14:02:53)

  • Registered: 2007-07-08
  • Posts: 22

Re: Fireface 400 Windows 7 64-bit crashes

Running windows on a mac is not supported by microsoft and is not the same as running it on a "real" PC.  I can't speak for RME, but why would they be responsible for people running their hardware/software on unsupported machines. Windows on a Mac is one of those "use at your own risk" things and I'm always surprised when people wonder why things go bad. Need windows, buy a PC, problem solved.

And who works on a song while installing things in the background? It seems you're trying to go out of your way to make things as unstable as possible.

Anyway, buy a PC and problem solved. That is the only full proof solution ( or use OSX, not windows on your Mac ).

19 Reply by mdl (edited by mdl 2012-03-05 15:46:57)

  • mdl
  • Banned
  • Offline
  • Registered: 2011-10-12
  • Posts: 8

Re: Fireface 400 Windows 7 64-bit crashes

Timur, no, I'm using the default output plugin, and I've tried with multiple cables as well. (Keep in mind that the 400 was completely solid under OS X, so I really find it hard to believe that it's a chipset issue, especially when this machine has the recommended TI chipset.) Also, it's possible that it's not on all Intel Macs, but all the ones I've tried (MacPro1,1 and MacBookPro5,3, and I've heard reports of problems on certain Intel iMacs) have shown the problem.

20 Reply by mdl (edited by mdl 2012-03-05 15:58:36)

  • mdl
  • Banned
  • Offline
  • Registered: 2011-10-12
  • Posts: 8

Re: Fireface 400 Windows 7 64-bit crashes

gamerx wrote:

Running windows on a mac is not supported by microsoft and is not the same as running it on a "real" PC.

Microsoft doesn't give two tugs of a dead dog's dick what you run it on; there has never been an "unsupported" Windows configuration beyond not meeting minimum system specs. Also, I like how you put "real" in quotes. Would you care to elaborate? Wait, you can't, because it is for all intents and purposes a PC, you massive cunt.

I can't speak for RME,

Then don't, as requested in the very first post. And hey, look! Even RME claims support on some "Microsoft-unsupported" configurations! (I'm linking this page because it's linked under "tested systems" off the page for the UFX--yes, the UFX, but the page linked to says UC.) Why do you people exist? Do you find it remotely constructive at all to sit around telling people that their problems either don't exist or that it's their fault for having them?

but why would they be responsible for people running their hardware/software on unsupported machines. Windows on a Mac is one of those "use at your own risk" things and I'm always surprised when people wonder why things go bad. Need windows, buy a PC, problem solved.

Sure. Want to fix my problem? I accept PayPal.

And who works on a song while installing things in the background? It seems you're trying to go out of your way to make things as unstable as possible.

What I have provided is extremely valuable--a way in which I can reproduce the bug every single time. Have you ever submitted a bug report for anything in your life? Have you ever developed software? Have you ever even written hello world? Thanks for your remark, champ; I assume if you were having this problem, your report would consist of "MY SHIT DOESN'T WORK, DIDN'T BOTHER TO TRY TO FIGURE OUT A CASE WHERE IT CONSISTENTLY HAPPENS, PLZ FIX".

Anyway, buy a PC and problem solved. That is the only full proof solution ( or use OSX, not windows on your Mac ).

Why don't you just get the fuck out of my thread instead of being another worthless apologist support forum toady?

  • From: Germany
  • Registered: 2007-04-10
  • Posts: 9,782

Re: Fireface 400 Windows 7 64-bit crashes

Thread closed and user banned for insulting other forum members. If you wish to repost the issue in a civil manner, please c&p the relevant passages. I will move the thread by tomorrow or so.

Just for the record, the (now quite outdated) list of tested systems is by no means a list of "officially supported" or "recommended" systems.


Regards
Daniel Fuchs
RME

Regards
Daniel Fuchs
RME

RME Support's Website