hey guys, am I the only one over here experiencing this Bluescreen on 2 different PCs in all possible configurations with 3 different firewire cards?
Admins please????

the same here with the FF400.

Seems that the RME drivers are not so rock solid as claimed. Since Win7 I lately experienced a lot of trouble with blue screens.
The RME support was no big help so far.

Sorry guys, but don't tell me all the time it's the chipset or the cable.

lately I either get a blue screen or have to reboot after a FF400 connection is broken or if I switch on/off the F400.

Even if it is the chipset or the cable:

why is the reboot necessary ? Why the blue screen. Shouldn't the driver be capable of reconnecting ?

For me this is clearly a driver issue.

Latest Firmware: 1.70 , Latest Drivers: 3.031

As a matter of fact you must be lucky, since all of the above users are experiencing something different.
I bought the FF400 exactly because it was claimed that the drivers shall be rock solid.
But my reality is that I really have a lot of trouble. This is IMO not acceptable considering the high price the gear costs !

Maybe the reason is my Firewire connection which is 10 m long (using Lindy FW repeaters).

BUT: the fact that the system is crashing is not acceptable even if the cable is crap.
A good driver should handle lost or instable connections without bluescreen in my opinion.

For me it looks like driver stability has decreased since Windows 7.

Anyway, I'll try to exchange my Firewire Repeater cables and use  the following instead (with TI Chipset):

http://www.ieee1394-produkte.de/Firewir … 4-340.html

But maybe my problems are related to high voltage peaks in my room. Sometimes when switching on devices or the light
I lose FW connection, too.

So I'll try this device, too:
http://www.ieee1394-produkte.de/Firewir … 4-820.html

Driver 3.034 is the latest, already released on 12/17/2010. Please try that one.

I think I've solved the issue in my setup:

problem was the additional FF400 power supply.
Sometimes when I switched on electrical devices like Monitors, the light or amplifier there occured some kind of electrical impulse
which obviously affected the additional power supply. This resulted mostly in a hang up of the FF400. After switching off/off with the
switch on the backside I got various results: either resuming operation with sound, resuming operation without sound, or bluescreen.

I can reproduce this very well. Without the power supply everything is running fine and stable.

So 2 x 5m cascaded cables (including mini repeaters with agere chips) seems to be ok.

Yllet: cable ? Length, high quality ? Tried a dedicated FW TI chipset card ? Any problems with concurrent drivers etc. - maybe the old saffire stuff ?

My system is running now stable on a 10m firewire connection (with bus powered repeater cables).
No more bluescreen since removal of the additional power supply.

Are you using bus-power or the dedicated power-supply of the FF?

Does it make a difference if you are using the Desktop or Always On power-scheme vs. the Laptop or Minimum one?

So what happens when you use the power-supply? To make sure that it's not your board not being able to handle the power-draw you should give this a try first.

I encountered this problem twice today.  After the second time, I went to Google.  To my surprise, a search for 'bsod "target_mdl_too_small"' brings up posts on this forum as the first two hits!

I ran a utility to analyze the minidump file, and sure enough fireface.sys was identified as the driver causing the problem:

According to MSDN, this is the cause of the problem: "This is a driver bug.  A driver has called the IoBuildPartialMdl function and passed in an MDL to map part of a source MDL, but the target MDL is not large enough to map the entire range of addresses requested."

Here is their suggested resolution: "The source and target MDLs, as well as the address range length to be mapped, are the first, second, and fourth arguments to the IoBuildPartialMdl function.  Therefore, doing a stack trace on this particular function might help during the debugging process.  Ensure that your code is correctly calculating the necessary size for the target MDL for the address range length that you are passing to this function."

I provided a link to my minidump file in a previous post (but the post was subsequently deleted).  I still have the minidump file, which I imagine would make it much easier for your engineers to fix this problem.  Let me know if you'd like me to post it again, or if you'd simply like me to email it to you...

MS minidump files are useless with such problems. As you can see by yourself, the cases of users with BSODs are extremely rare. Reading this thread you will also see that usually a different issue triggered the BSOD. None of these rare BSODs are reproducable, so they can not be further examined from us.

There is no difference to the minidump - the kernel memory dump still doesn't give info where exactly this and why it happened. We have some experience with this as we had to fix various of these BSODs over the years. The current drivers are matured, and only allow further improvement if a BSOD is reproducable. If it happens as rare as with you, and you are already a rare case yourself within the multiple then thousands of users world-wide - then I see no way to fix this from our side.

Like I said before, the BSOD might be triggered by something special on your computer, and it makes more sense to try to find that. Starting with a different FW cable, over checking the FW drivers, trying a different FW port, up to unneccessary background processes - there can be a lot of reasons why this happens.

BTW, you did not connect USB and FireWire at the same time?

I could not read that info out of your posts. So set at 128 or 256 it runs stable?

Three days have passed at 128 samples.  I have not shut down my machine (using it regularly), and have had no bsods.

Would you like me to try another buffer size (96 perhaps), or would you like to wait longer to see if anything happens?

I think it's fair to say at this point that the workaround is to just use 128 sample buffers.

I'm still willing to help your guys track down the issue occurring with 64 sample buffers.  Do you want me to send the kernel dumps to your engineers? 

I'm also willing to look into the problem myself, but I will need the symbol files to be able to debug the kernel dump.  Is your team willing to send them to me?

Matthias?

Hi,
I also have been getting this bluescreen with the target_mdl_too_small message.

FireFace 400
Driver version: 3.067
Hardware Revision: 1.71

Texas Instruments 1394 OHCI Compliant Host Controller
Win7x64 Enterprise SP1
i7 CPU 950 @3.07GHz
16GB RAM
NVIDIA Quadro FX 5800

I've had my buffers set to 128 so I'm going to try 512 and see if that works.

Every BSOD I've gotten has happened right when I try to play a sound. One time was in Sound Forge, another was with Media Player. Seems possibly related to having multiple applications open at once that can play sound.

All of those who are still experiencing Blue Screens. Did you make sure to switch the windows power profile to "High Performance" (instead of the default "Balanced")?

Did you try both with and without the external power-supply?

Did you try a different Firewire Port/card?

Did you try to switch the Firewire driver to "(Legacy)" via Device-Manager?

If you are using a NVidia GPU also try to switch to the Microsoft Standard VGA driver via Device-Manager.

I guess my reply was more meant for pfoxsounds who is using Windows 7 and a FF400.

The "legacy" option is not available for XP.

What do you exactly mean by "power management disabled"? Does it make any difference to use the "Always On" or "Desktop" profile?

Are you using any vendor specific IDE/AHCI drivers?

What other Firewire cards did? I would have to search, but some people reported in the past that they had to edit SIDspeed for their FW port via Registry. I mean to remember that we had some SP3 related posts here where people tried older version OHCI drivers, but again would have to look that up, so take that with a grain of salt. Maybe try those search term yourself, too.

I believe Matthias' postings # 23 and 25 sum up our position. As there is no known general issue of the FF800 at low buffer sizes, we can only assume that something in the context of your entire specific system setup is causing a problem when the audio software is required to render a signal at e.g. 64 samples. This could have all kinds of reasons. More often than not, users report problems to vanish after the removal of some exotic hardware or software component that was never even metioned before.... Any such thing you could try on your system?

Also, can you test the FF800 with another computer?

This is a perfectly normal procedure everywhere - initial inspection/testing of a device outside warranty which is sent in for  checking/repair will be charged... The amount would be set off against the amount charged for repair, but if no repair is performed (e.g. cost too high for the customer), or if no fault can be found, the initial charge remains...

Regards
Daniel Fuchs
RME

This is not true --- while I am using an XP based laptop system, it is perfectly stable at higher buffer sizes, but BSODs when using 64 sample buffers after about a day or two of use.

Note previous post:

Hi,
So at 512 samples I made it about 2 weeks without a BSOD, though I was away for a couple days last week.

I am already set to High Perfomance
I have run with and without the external PS
Only one FW port on this machine so no option to switch
I just switched FW to (Legacy) so once I reboot we'll see how it goes
I don't think I want to mess with video drivers as I use this machine in production right now with Maya and other things that will not be OK with the MS Standard driver!

I have one other guy on site with me here who has the same RME 400 and other software as me, and I don't think he gets BSODs. Will keep thinking about it. I don't know if he uses Google Chrome, but the last BSOD I had today happened after I'd been listening to Google Music on the Chrome browser for a while. I'd had the RME stop passing sound a couple times today after listening to music via the browser this way and then stopping it to listen to a sound file played with Media Player. Only way to get the RME to play sound again was to power it down and back up again.

Thanks

Oh, and hallo vetter Fuchs!

The NVidia vs. Microsoft driver thing was meant for testing, not for production. There are issues with some Nvidia GPU + driver combinations, but usually these are rather performance than stability issues. Still worth checking.

Makes sense!