My concern isn't that I'm going to send in a working UFX; rather, I'm concerned about whether or nor RME's test suite will reproduce the error.  Specifically, this BSOD happens anywhere from once every two days to twice a day, under working conditions (i.e. the error does not happen in a static state).  Adding to my concern is RME's lack of confidence in reproducing these BSODs (as they have stated in this thread); basically, they don't expect to be able to reproduce the error.

On the other hand, I am able to reproduce this error on two computers here, using multiple FW interfaces, cables, and ports.  However, the error (as always) is intermittent; it won't happen immediately, it will still take (on average) a day of use to produce it.  I could easily just turn on the computer, show that the UFX appears to work properly, and then declare it functional.

I imagine a scenario where I send in the unit, a tech runs through a set of tests, verifies that the tests completed successfully, and sends me a bill.  This does not serve either of us very well; they never find the cause of the problem, and I never get the fix.

Of course, I would expect a better outcome if they were able to  reproduce the error, and the cause were tracked down.  Since RME has low confidence in their ability to reproduce the error, I'd be willing to send in my computer with the UFX so that they could witness the BSOD and track down its cause; as I've already shown, the driver that is identified by the operating system as executing the faulty instruction is RME's.  If they had both my computer and the UFX in question, they could analyze the problem.

My apologies for asking you questions that are better answered by RME (if at any time RME wants to jump in and participate in this thread, it would be most appreciated).  It's not that I expected you to speak for them, it's that I expected them to respond themselves; this forum is the only form of customer support that I know of (unless I am missing something?).  For whatever reason, they have been noticeably silent.  Should I be emailing them instead of using this forum?

Regarding driver version 2.9992: the readme specifies that this driver is for the FF 400 / 800; the UFX is not specified.

Yes.  I've never used the UFX via USB with low buffer settings for any significant amount of time because of audio drop-outs.  These drop outs only happen when connected via USB, and only then with low buffer settings, so I just stuck with FW.

I'll test it to give you an answer.

Timur, despite the thread title, we are now dealing with a UFX.. ;-)

After 1 week of testing via USB, the unit did not BSOD.  Of course, I could not lower the buffer settings all the way down to 64 samples, which is the only setting that creates BSODs via FW.

(@Timur) Thanks for all of your suggestions; I appreciate the effort you've made to help me.  At this point, I need to get RME's attention; I can't afford to buy a computer without knowing if the unit itself is at fault.

(@RME tech support) I'm at the end of my rope here, guys.  It's been 2 months.  It's not as though I've been impatient or discourteous here in the forum.  I've followed all suggestions: I've tested the UFX with another cable, another FW port, another FW chipset, and even another computer, and the results are always consistent: the unit will BSOD after 1-2 days of usage, and the driver executing the bad instruction is identified as fireface.sys, the RME driver.  My unit is under warranty.  You've already told me you expect to find nothing if you look at the unit, and thus I should expect to throw my money away if I chose to send it to you.  Is this all that you are willing to do to help me?

I must apologize if my expectations are out of line, but what I was expecting was to be able to send in the unit for analysis without having to pay.  After all, the unit is under warranty, and there is little evidence to suggest that the unit itself is not at fault.

I agree that the fact that fireface.sys is the driver that executed the bad insruction does not mean that your driver has a bug, however it does mean that it is the driver that executed the bad instruction.  Of course, this could be due to many different reasons, some of which are under RME's control, and others that are not.

In other words, this BSOD could be because of an RME driver bug, a hardware failure, or a problem elsewhere in the system; all three scenarios can (and do) produce BSODs of this type.  Given that I have reproduced the problem on two different computers seems to indicate that the machine itself is not likely the cuprit.

So far, the only suggestion that remains is that I buy a new computer; all other suggestions have failed to correct the problem.  Spending that much money without actually knowing where the problem lies seems a bit reckless to me, especially considering the fact that the problem did occur on more than one computer.

One way that I could eliminate the RME hardware from this scenario would be to buy another UFX, test with it, and then return it.  I would hate to do this to a vendor, but it seems that I am running out of options.  Any suggestions remaining?

Below are the screenshots.  No UFX attached:

UFX attached, running straight mic->headphones at 64 sample buffers in Reaper:

A side note: when I installed the USB driver, I got another BSOD on shutdown: driver_power_state_failure.  I checked that my firmware was up to date; it was, with the exception of the DSP firmware (it was set to 1.48).  I updated the firmware and restarted.  Then I took the screen shots.

As before, 64 sample buffers works while connected via USB, but there is consistent crackling.  Thoughts?

Hard drive is IDE.

All USB devices were disabled (went as far as disabling the usb hub that the smart card reader was connected to).  WLAN and LAN devices were disabled as well.

I had stripped the system down pretty bare (followed XP tweaking guide here: http://www.tweakhound.com/xp/xptweaks/s … aks1.htm), but I still had the DVD drive enabled, so I disabled it this time around, and repeated the test.  No change.

There is no crackling when the sample buffers are set to 128 samples.  Here is the DPC screenshot for 128; it is comparable to 64 samples:

If I can find time I can carry my UFX to a customers Windows XP desktop machine that offers both FW and USB. Once I did that I can report back with how it performed there. 128 samples might be what you have to settle on with your machine.

Don't hesitate to tell us whether that "new unit" is also a FF800 or something else...

Regards
Daniel Fuchs
RME