Please share your experiences with delayed write failures under Windows. Your entry will be immediately added to the bottom of this feedback forum. Thank you.

Thank you for providing your delayed write blog. With its help, I was able to resolve delayed write failures that were caused by my Oxford Semiconductor based 1394 enclosure. Thanks again.

Hi,
I've got a problem. While I was updating the firmware of my pl-3507 something failed, and now it has no firmware. the computer doesn't even recognise that there's something connected to it, and the flashing tool doesn't work. Has someone an idea of how I could solve the problem? I thought of writing the hex file directly to the usb port with a homemade program, but I don't know if that would work...

Spider,

That's a difficult one. It could be that the upload somehow aborted in the middle, thereby leaving the firmware in an incomplete state. It could also be that the wrong firmware was uploaded.

Regardless, if the device/firmware was designed properly, there should always be a fallback mechanism to allow a reset of the firmware if such failures occur. Whether such a safety mechism exists for your product is unknown to me. Your best bet is to check with the distributor of the download program to see if they have any ideas. Honestly though, you may find technical support to be limited in this respect. Good luck.

Hi there,
first i encountered troubles USB only HD enclosures. One of those was the "Delayed Write Error" while writing mft/$ fired up by 250Gb Maxtor USB case, we experienced the same error with other drives on that pc but the Maxtor locked the system .

Tips that should help with firewire , too :
* Look in your Windows Sytem Event , if you see a lot of Disk Failures , then you know you are in trouble.

* Don't power off your drive immediately

* Close all Apps and try to use the "Safely remove drive" feature from the taskbar

* Shutdown windows if the "Safely remove drive" feature did not help you

* At www.raidsonic.de under support/downloads you'll find a full version of file scavenger 2.1 (for customers of their Prolific PL-3507 diven Cases hehehe )

* @Active Filerecovery is also a good tool which brought me back the files with their names and directory structure

*We encountered that there are firmware patches for the ide bridge chips inside the drives on some linux forums. Open your drive look at your chipset, get the upgrade.

We switched to an old Firewire/USB enclosure to work around the usb connection problem and looked for the chipset, it is a PL-3507 which send me here (the chip is inside raidsonic's Icy Box and the techsolo copies, too), even if the drive never failed before , but you had to connect it to the pc before you boot windows and it stays disconnected after returning the pc from standby.

Tips for upgrading a drive with PL-3507:
* Get the "fw_pl3507B_d010705.zip" file from
http://tech.prolific.com.tw

*Connect your case via USB

*I used romwriter 2.2.1 software for the upgrade from 2003_05_20_218
to 2005_01_07_204

*After the upgrade , "safely remove the drive", turn off the drive, close romwriter.
You will read the old rom version if you don't do this

*Reconnect hte drive, maybe on another USB port, open romwriter, check your
rom version, should be the new one.

* Use Romwriter 2.0.4 if 2.2.1 won't work. Or maybe you own a revison A chip, which is not usb updatable.

* Raidsonic says you should drop your partitions , create new ones an re-quick-format those, after the firmware upgrade. I did not do that, my drive is
still ok.

Thank you for all the tips!

Thank you so much for your hard work helping people with the delayed write failure problem. Your blog has been invaluable to me and I want to share my experience resolving the problem.

My Kingwin USB/1394 enclosure works fine on my brand new ASUS mobo at work with AMD dual-core processor. At home, on my PIII-S Tualatin machine the drive was having terrible problems with the write failure.

I was running Win2k SP4 and couldn't get anywhere. Installed Max128k filter driver and no luck. Ugraded the Prolific PL-3507 firmware to the latest 2005 release and still no luck. The firmware can be found here:

http://tech.prolific.com.tw/visitor/v_fileBrw.asp

The firmware you want is:

http://tech.prolific.com.tw/visitor/fcabdl.asp?fid=35085856

At this point I decided to upgrade to Windows XP Professional so that I could install the hotfixes you mention at the top of the blog: 885464 and 887170 . After SP1, I still had no luck. So I installed SP2. Guess what? Delayed Write Failure.

At this point I wanted to install the hotfixes but you need to actually call Microsoft to get them. So I found two sources on the net where you can download them. If you have BitTorrent, go to:

http://thepiratebay.org/details.php?id=3375013

And download the hotfixes there.

Another great piece of software is AutoPatcher, available here:

http://www.neowin.net/forum/index.php?showtopic=334257

(BitTorrent)
http://torrent.autopatcher5.mirror.ineedhosting.net/mystats.php

After installing these two important hotfixes, you will be surprised to learn I STILL got the write failure.

At wits end, I finally uninstalled max128k and installed:

1394MaxRec_v127.exe

which was mentioned in the blog.

I am now able to transfer files to my hearts content. The process took three sleepless nights. I haven't had a hardware problem this bad since I tried to install a sound card in a Windows NT Server box around 1997.

... addendum to previous post:

First, for those of you justifiably concerned about the legality of the BitTorrent downloads, to the best of my understanding they are legal. I am not aware of a prohibition on distributing hotfixes, and in any event this site is not distributing them.

Second, in my effort to solve the problem, I fiddled with nearly every motherboard BIOS setting with no luck. My PIII machine has a 1394 port from the Creative Audigy 2 ZS sound card, and my Raptor hard drive resides on a Promise SATA150 TX2 Plus controller. High speed USB is supplied via an Adaptec 4-port PCI card.

All this led me to wonder whether the PCI bus was not getting overly "saturated". To counter this, I added wait states to both PCI read and write, killed PCI Dynamic Bursting, enabled PCI Delay Transaction, and played with a few other settings. None of these changes altered the problem in any way.

The Delayed Write Failure has been a nightmare. The past three nights I have felt like Martin Sheen at his Saigon hotel room in the film "Apocalypse Now". I hear the choppers, I am swaying deliriously to the Doors as I clean my rifle, the drugs are kicking in. In my quest to find Kurtz, I have gone "native".

Again, thanks.

hello, found this site after i changed out my hardrive from my maxtor one touch 250gb hdd. i've since changed the drive to a hitachi 250gb. unfortunately i need to flash the maxtor firmware to the oxford firmware. i've tried getting the buslink utility, tried maxxi's way with the flash011.bat, and it is unable to enter force flash mode. windows device manager shows that it is there. i've tried to plug it into my onboard TI chip with no luck. it works only when connected to the audigy2.

Hi all,
I got myself an

akasa integral combo enclosure 3 months ago. Unfortunately the combo is based on Prolific 3507. Needless to say, I am seek of restoring my data every other week.

Is the partition corruption related to the "Delayed Write Error", or is it a separate problem for Prolific 3507?

I have tried upgrading using different versions of the firmware loader from prolific, but I always get "Can't access the chip.(be rejected!)" errors. Can anyone give me a hint how to get past this error?

On another forum someone suggests removing a resister from the circuit board. While I have the right tools for this job, will it be any good?

TIA

And of course I am sick, not seek :-)

Hi,

Prolific has released a new (?) firmware numbered 2005.09.06.187. But what is strange that 187 is smaller than the latest 204. Also there is no changelog. Does anybody know what it is? I should avoid it until Prolific clarify it.

Hi all victims with PL-3507,

I'm also a victim of the buggy chip. I own a 'Hi-Speed' brand 2.5" HD enclosure, Hitachi 60GB HD and a Dell Laptop Inspirion 6000(win xp sp2).

Firewire: random "Delay Write Error"......
USB 2.0: NO PROBLEM!!!!

I cannot update the firmware as it is chip A version!!!!
I want to refund for this sick enclosure.....

I suggest everyone should check it is NOT a PL-3507-chip enclosure before you buy a HD enclousre or you will have a painful experience of HD failure/bad sector.

If you are already a victim like me, perhaps this fix(disable the SMB service by tweaking registry) may help you, pls test at your own risk:

http://www.tangent-systems.com/support/delayedwrite .html

Is there anyone who can help me please! I purchased a usb 2.0/IEEE1394 Enclosure(CD_RW/DVD_RW/IDE transfer) Model: P550c, it has a Prolific PL-3057 chipset and a PMC Flash(NK75L) chipset connected, via the iLink port, to a Sony Vaio PCG-FX103(Texas Instrument 1394 net adapter[OHCI compliant IEEE Host Controller])but Windows XP does not show the Enclosure/IDE(80GB) drive for me to transfer files off my laptop.I have been 7 days on this problem(on/ff) without success, even though i finally managed to update(sp1+sp2)my XP Professional. I even went to the Prolific website and downloded/flashed the firmware, without any joy! Under Control Panel/System/Device Manager the unit is now visable when connected via USB or he iLink port(after a long delay) but i still can NOT get access to transfer my files.I have tried the exccellent utilities provided by busTrace and the unit is highlighted, tried the data read/write utility on the D: drive(only c: and D: highlighted) not sure if this(D: drive) is my 1394 Combo Enclosure as I partitioned C: drive(10GB) a year ago. Tried to install the provided CD rom/downloaded USB drivers and others from different sites without success. The firmware seems to flash the chipset but there seems to be no difference and no access to the IDE in my USB/1394 Combo.I would advise anyone NOT TO BUY this device (P550C-PL-3507 chipset)Any recommends would the gratefully appreciated

I just bought a Medion 250GB external drive, found it used the PL-3507 chip and became somewhat worried when I read this and other sites about problems with the chip.
I have copied some 40+ GB onto it over the Firewire port (from a Dell Inspiron 6000, XP+SP2) with no problems at all. The 1394 Hard Drive Tester program completes successfully in 147 seconds. The PL-3507 has firmware dated 2003.08.13 (amazingly old for a unit manufactured in 2005).
I will keep my fingers crossed and hope not to have any problems but at least I know what to look for if I do have problems in the future.

Hi David,

I got the same Notebook as you(also same firewire device as you)
Have you applied a firmware update on your Notebook?
Is your firewire cable well-shielded?

I just wonder is the problem of cable quality.

Manolis and others,

You cannot upgrade the firmware when the drive is connected via the FireWire 1394 port. You must connect through USB in order to upgrade. Also, version A of the #$%@!! Prolific 3507 cannot be flashed, only versions B and C of the chip.

The latest firmware is from August 2005 and you should definitely upgrade to the latest.

Hi all again,

I own a 'Hi-Speed' brand 2.5" HD enclosure, Hitachi 60GB HD and a Dell Laptop Inspirion 6000(win xp sp2).

Web-site: http://www.win-best.com/products/exposure/hd_d4_u2/hdd4u2_ch i.htm
I did send mail to their sales dept "sale@win-best.com" abt the problem, but no response at all.....(maybe they do not investigate the error as they have already got your money in their pocket)

So, I finally updated the firmware of my laptop.

The write delay problem seems to be partly solved. I cannot reproduce the error with the test file "1394test.exe" provided here. HOWEVER, when i browse and move files from the HD when using 'NERO BURNING', Write Delay Error again....

Really don't konw how to deal this crazy error...

i have a problem with fantec external drives.
when i connect port 1 of the external cast to the computer it works fine, until i connect the powersupply of another external case (which is not yet connected to the computer) or start another computer. then the external drive disconnects and reconnects.
i even have the effect when the connected device is serveral meters away from the external drive.

I managed to acquire the http://support.microsoft.com/kb/885464 patch from a Compaq Support pack. Luckily my problem was on a Compaq Armada so I could run the SP. YMMV.

I got the SP from here -

http://h18007.www1.hp.com/support/files/Compaqtabletpc/u s/download/22721.html

By default it wouldn’t install 885464 on my laptop because it didn't ship with a 1384 controller. So I downloaded Process Explorer from sysinternals.com and suspended the package when it had unzipped all its files ready to install them. I found the 885464 patch under -

C:\Program Files\HPQ\SED\US\885464\WindowsXP-KB885464-x86-enu.exe

I think if you suspend the setup process during any part of the actual full screen "Installing Windows Hot fixes" bit you should be able to grab the 885464 patch. Actually you probably don’t need to suspend it at all now you know the proper path :-P

Getting this patch was the final fix after sending various drives (HDD and DVD/RW) back, along with trying two PCMCIA FireWire adaptors and a PCI one in the docking station. ARGH.

But I THINK I'm back to "its fast and it just works" with all this FireWire stuff.

If you ever doubted how much better FireWire is over USB run HDTach over your external drive once connected via USB2 and again via FW. Not only do you get marginally more throughput but the CPU usage is about 1/10th as much as USB2.

Cheers,

Luke
Recovering FireWire Evangelist

For anyone running 1394Test.exe in a "locked down" (non-administrator) environment, you might find that the tool stops after displaying "TEST IN PROGRESS ON DRIVE x: PLEASE WAIT...". Once I ran it with administrator rights, the program ran successfully.

Hello,

I'm running two 4-bay firewire towers that use the Oxford 911 chipset with a total online capacity of 2 Tb. I use a total of 3 firewire PCI cards in my server (Server 2003) with chipsets from VIA, TI, and Bustek. I also have 2 500Gig Lacie Big disks that I use for backup.

I tried everything else in the forum, including upgrading the firmware on the 911 bridge. I lost one bridge that way, but it didn't solve the problem.

I finally fixed the problem when I change the way Windows manages the hard drives. I find that the problem invariably occurs if I set Windows to spin down the drives when there's no activity. When the drives are always powered up, the problem never occurs. I've been using the always on configuration for the past six months now with no problems.

I have a mix of Maxtors, Seagates and one Hitachi drive. It might be that one brand doesn't like being powered down, or takes too long to spin back up. Interestingly enough, the Lacie BigDisk has never had a problem. I'll do a bit of investigating and report back.

Hi!

I'm experiencing the same fault as you guys, and I too have the Prolific PL-3507 chipset in my HDD caddy. I also have a Firewire only caddy for my DVD-RW drive (NEC-4550a) which works fine!

I downloaded the Microsoft hotfix from one of the forum sites but it's bl**dy encrypted isn't it? Can't bl**dy install it can I???!!! tried Zip crackers and allsorts to get the encryption key to no avail :-(

Therefore, if I can't get anything to work I'm gonna get shot of my HDD caddy (a Safecom 3.5" Firewire/USB2.0 combo) to a mate who can use USB2.0 instead of Firewire as it appears to work fine that way.

My PC is a Sharp PC-GP2520 Notebook (P4 2.0GHz - 512Mb DDR - running XP Pro SP2) and unfortunately doesn't have USB2.0 connection.

Hi!

After ages of trying I finally have Microsoft fix 885464, if anyone wants it, e-mail me at p.dixon0@ talk 21.com (remove the spaces).

Regards

Paul Dixon

Hi,

I found these patches from HP.
(SP30892 fixes)
http://h18007.www1.hp.com/support/files/Compaqtablet pc/us/download/22952.html

The collection includes WinXP KB885464 issue (SBP-2 drive stops responding when you try to write data in Windows XP).

I have not tired it yet, so I can't comment on this. I am trying to solve my DVD writer with GL711 external enclosure issue.

very good site!

Hello, you have very interesting site!

I seem to be able to write big files to my Prolific PL-3507 based Firewire+USB 2.0 enclosure in Firewire mode with no problem, even without the max128k fix. However, trying to write to a partition on a drive in the enclosure will hang cause a catastrophic data loss (along with a delayed write error message after a long while) IF and ONLY IF attempt such writes after bringing up Nero (6.6.0.14).

The Firewire-connected drive and its contents will show up fine under Nero, but afterwards, any writes to that drive will result in the drive getting nuked!

Looking for a solution, I found your page, and surely enough, trying 1394test.exe results in a failure at 14% trying to write 257 blocks. Since my PL-3507 is revision A, I had to resort to installing max128k. After this, 1394test.exe will run fine.

HOWEVER... this does not solve the _original_ problem... even with max128k, if I start up Nero and access the drive the same catastrophic data loss occurs. devfilter.exe shows that max128k is still there, so it seems that Nero is causing some other unknown side effect.

For those people wishing to see if they experience this same problem with Nero on their PL-3507 driven Firewire enclosures, my advice is to create a small dummy partition first and try to write to that, otherwise there is a VERY REAL chance of all the data in your drive going poof!

Note that the presence or absence of hotfix 885222 (which is supposed to supercede 885464) does not seem to make any difference with the problem above.

My experience was outlined here: http://forums.storagereview.net/index.php?showtopic=21079
Basically, I believe that I experienced a delayed write problem, which subsequently hosed my drive, on a Prolific PL3507 enclosure with 10-06-2004 firmware. Now according to some of the previous posts, the issue was apparently resolved in the 09-22-2004 firmware. This is most likely false. You must be sure to flash with the latest firmware, as of this writing 09-06-2005 as I have just done.

I hope my drive never crashes again. I'm still going to use the Max128k filter driver on my Win 2000 Pro SP4 system, especially since the KB885464 hotfix is only for Win XP SP2.

summary:
windows 2000 sp4
prolific 3507 enclosure bridge
seagate 250 gig ata drive
firewire port is on my creative sb audigy card

as far as i have been able to ascertain, the problem is between my firewire chipset and the prolific bridge because a different enclosure worked flawlessly with the sb firewire port and, as i have just discovered, the prolific enclosure works flawlessly with a ti firewire card. i'm not sure how to find out what chipset my sb audigy card is using for the firewire port and my next step was to try to update the drivers there but i have apparently solved my delayed write failure for now.

i say boooo to prolific. they seem to be the most common thread in all these dwf issues.

forgot to mention:

i upgraded my firmware to the newest version (110904 found here: http://member.newsguy.com/~siccos/PL3507%20Firmware.htm) but that didn't work.

i installed the max128k filter driver and that didn't work.

i installed 1394MaxRec_v127.exe and that didn't work.

the only thing that worked was using a different enclosure or a different firewire card. i think what i had (mentioned above) is incompatible.

Resolved my problem by getting rid of my Prolific chipset caddy and purchased another Firewire only caddy :-) Happy days!!!

Paul Dixon

Partial success....

I have been wrestling with the problems of 1394 external drives for over 2 years now, and I have *finally* achieved some measure of success. Not total success, but close enough that I will now give up on the seach.....

I have seen just about every failure imaginable; in the beginning, the external drives seemed to work perfectly fine out of the box: no errors, no BSOD, no "delayed write errors", etc. But then I happened to turn on verify on a backup process that was writing to the disks, and I found that the data being written out to the drives was not being read back the same! Silent write errors are the *WORST*!

My external 1394 drives are Mapower units based on the once-ubiquitous Oxford 911 chip, with USB2.0 and 1394a interfaces.

Various efforts at applying MSFT patches and upgrading the 911 firmware alternately left me with BSOD's, "delayed write failure", total machine lock-ups, etc. No fun at all. But at least the drives were fast!?

Anyway, long story short, the updrading the Oxford 911 firmware to the version of 15 October 2004 and also applying the MSFT KB885222 patch has gotten me to the point of no more errors. While each drive works well alone -- one drive busy at a time -- any simultaneous use of both drives will take a ***VERY*** long time to complete; copying a file from one 1394 drive to another may take 10-20 times longer than first copying it to an internal disk and then back out to the other drive. IOW, there seems to be some problem with bus arbitration when the bus is busy still remaining.

I found the "HashCalc" tool by Slavasoft to be hugely helpful in testing the various changes/configurations along the way; keep in mind that absence of filesystem errors is not necessarily success!! You really do need to check to ensure that the data on the drive is what you want it to be....

Some notes on upgrading the Oxford firmware:
1) I found the Windows based firmware uploader tool to be more reliable than the Java based version
2) If you do upgrade the firmware, be sure to do this on a machine that can sustain a BSOD or other lockup; I had lots of these in the process of flashing the 911 chips. Often times the BSOD was caused by a driver mpool corruption error originating in "oxminifw.sys" -- suspicious name!!
3) Every device on the 1394 bus needs a unique device ID; in the case of the Ox911-based bridge cards, the unique ID comes from the "Chip Id" field at the top of the configuration page. If you load the factory default "baserom.bin" file, you will need to manually set the Chip ID back to the value the device manufacturer assigned (or to some value that is unique on your 1394 network).
4) I found that I could not get two drives to work on the bus simultaneously at all if they were set to max transfers of 2048 bytes; cutting back to 1024 works. With two drives at 2048, not only did simultaneous use result in ***VERY*** long delays, but there were silent write errors as well. With the 1024 setting, simultaneous use is very slow (the drives actually seem to hang for mintes at a time, with no transfer activity), but no errors occur (it all gets done in the end).
5) You can use the various other text fields on the settings page to label your drives so that you can tell them apart in the Windows "safely remove hardware" panel....
6) I found no improvement by cutting out UDMA mode 5, or messing with system virtual memory/paging file/etc.
7) I have not applied KB885464, but I don't know that it would really help; note that if you can obtain KB885464, you might want to look at KB885894 before installing it.

In any case, I hope this is helpful to someone; I really wish that these drives would live up to their promissed hype level, but at this point I am just glad that they store the data they are supposed to store! Unfortunately, I think there are probably a lot of people out there that have data stored on 1394 drives that is not what they think it is....!

-frank

As to the power management solution above, this has regularly worked for me. I am using one of the 8-drive enclosures (4 ox911 bridge boards).

WinXP is always flaky about recognizing the second drive (LUN1) on each board. I mean really fussy and unpredictable.

However, if I turn off power management, DWE goes away. This is deeply frustrating as this is a media storage tower and having all 8 drives spinning is a waste of juice and drive wear.

Does anybody have any ideas about why this is directly related to power management?

DOes anybody else have any issues with getting two drives (LUN0+1) working on a bridge board?

I too was a victim of this dreaded delayed write failure on my VIA based BIOSTAR U8868 Grand with an NEC based Firewire card and an IOGEAR Ion 320 combo usb/1394 drive. The problem manifested itself any time I tried to copy a file to/from the drive that was more than 1GB or so. I tried most of the things mentioned in this blog such as the microsoft fix, using Cacheman, changing the virtual memory settings to Programs/System and back, etc to no avail.

After a lot of testing I got the problem fixed with a combination of the 128K filter driver and changing my PCI latency to 64 from 32 (and reducing AGP video card latency from 248 to 64) with the PCI Latency utility found at http://downloads.guru3d.com/download.php?det=951 -- now I can copy a 4 gb file no problem though it must be said that this change has slowed down the drive considerably. Of course YMMV but this may be useful to someone out there.

I kept getting delayed write errors on my INITIO 2430L based boards. These are 1394b boards with quad drive support. I went though the entire list of solutions and nothing worked. So I decided to reinstall windows from a Windows CD instead of a restore CD. With base install all was fine. I began installing software piece by piece anbd finally determined the culprit was actually Norton Anti-Virus 2004 Pro. After removing NAV and installing AVG Antivirus I have been running 48 hours of sustained drive activity without any problems.

You have a best site!

Hi :)
After three weeks of fighting with USB (and knowing that my Techsolo 3550 with my Seagate 320Gb properly works on my seller pc), I found how to solve the problem of "Delayed Write Failures"... so easy as so... working! :)

Here it is:
http://www.seagate.com/support/ts/external/errors/01_common.html#delay

Good luck!

Respect admin! Nice site

I was using PL 3507A and OX911 with seagate 250G HDD.
Delayed Write occured on both bridges when I want to open certain AVI files or to do Norton SpeedDisk.
I didn't try MS's hotfix yet.
But I know for certain that the Max128filter is not the solution(Still thanks to the author who put lots of efforts on this).
I use this 1394HDD for capturing DV format files, which means data rate are conatantly keeped at a high level(13-28Mbps), and It never went wrong when I capturing.
Delayed Write or no response any more of my HDD always occur when I just want to open a avi file or file which will calls Vobsub plug-in.
I am not able to do something about it. But at least I put one more situation on this blog. Hopefully somebody capable of solving this will see my case helpful.

To me, It looks like some video codec I am using will cause SPB2 device having problem.
---
Basic HW conditions
Compaq 1500 laptop
TI OHCI 1394 interface
OX911 or PL 3507A with a Canopus ADVC110 are connected to a belkin 6 port 1394 HUB which connectd to the laptop.

Problem solved! (Probably by disabling the OXFW911 slave device option)
Hardware:
MSI K8N Neo2 (In Bios: disabled on-board firewire)
AMD64, 3500+
NVIDIA GeForce FX5200
1GB Memory
2*WD Raptor Raid0 HD config
Hoontech AudioDSP24 soundcard (on 2nd PCI slot)
Firewire card, with TI-chipset: TSB43AB23 (on 4th PCI slot)
Windows XP Pro, SP2

Firewire enclosure:
Oxford 911-based

I tried everything what had been described:
SInce I had the firewire enclosure, there were errors like 'delayed write failed'. On my previous computer, an asus CUSL2, PIII@800MHz. And on my current: an MSI K8N Neo2. On the MSI K8N Neo2, i experienced that some cables did not work very well, which worked fine on my previous computer. so I though problem had to do with cheap designed circuit around the on-board firewire chip: VIA 6303 (terminating impedance). Nevertheless, with cables that did work fine, I still had errors like 'delayed write failed' or 'I/O device error'.
1. Following all advices on this very interesting thread, I used the new 911 firmware 4.0 from:
http://fwdepot.com/firewiredepot/firmware/firmware.ht ml
This was not an improvement.
2. I tried an TI-based (TSB43AB23) PCI-card (Belkin FireWire 3-Port PCI Card).
This had a minor improvement. Now I could use all my firewire cables again. But still the 'delayed write failed'-error
3. I tried the KB885464 patch
This patch did not improve anything. Still the infamous error
4. Tried another Firewire enclosure.
This enclosure had also an OXFW911 chip. But with this enclosure I did not receive an error.
5. Changed OXFW911 chip configuration. Based on the findings from the previous step, I installed the OXFW900/911 ATA/ATAPI BRIDGE Uploader Utility, wrote down the Configuration Settings from the working enclosure, and copied them into the problematic Firewire enclosure:

Modify device configuration settings:
*Configuration ROM Editor:
ID/Version Information:
Chip ID: 07-006CAE
Vendor ID: 00027A
Hardware Version: 0F911
Common Text Strings:
Manufacturer: OXford Semiconductor Ltd.
Hardware ID: OXFW911

Master Configuration:
Master Device Type: Hard Disk Drive
Slave Configuration: Disabled

*Then in Advanced...

All I/O Modes enabled (PIO 0-4, DMA 0-2, UDMA 0-5)
Misc Options:
Max Transfer: 2048
GPI Drive Detect: Enabled
Detect drives with non-std. signature: Disabled
Wait 6s before polling drive; Disabled
Power drive on login (and fix master): Disabled

I think what really solved the problem was disabling the slave device option. (Max Transfer was already 2048, and the other Misc Options don't seem to have a large impact on it's function). I could imagine when no slave device is attached, and the bridge is configured as master/slave, there can be some wrong interfering signal, due to a wrong termination.

I copied now for the 4th time succesfully two very large folders (60GB in total) from my backup drive to the internal hard disk. The were no errors whatsoever anymore. Also causing a lot of other disc access (Searching files on my computer) did not seem to cause any error anymore.

Hi very good site!

I have several of Seagate's newer external USB/1394 combo drives (400GB model). They're connected to the Firewire port of the OEM Audigy that came with my Dell Dimension XPS (the blue one...). I noticed that when I copied large files *between* external disks, I'd get the delayed write failure eventually. I tried either chaining them or connecting one to the front port and the other to the back--no improvement. I tried turning off write-behind caching and repeating the same copy--this would allow the transfer to proceed for longer, but I'd get the DWF error eventually still.

Yet when I'd repeat the same transfer, copying from an external drive to the system's C: drive, for example, or a network share--no DWF. So there is some I/O glitch going from one external drive to another (same model, too). Already ruled out a defective HDD inside; even had to RMA one. I'm aware of Seagate's XP firewall suggestion, which was an interesting idea but it also hasn't solved my problem. For now I just have to copy files to an intermediary location or risk corrupting the file systems on my external disks.

Compaq Presario 6370US 2.53 GHz P4 w 1.25GB ram, XPSP2 Home. In past years I had one or two delayed write failures with a 60GB Maxtor in an ADSTech firewire enclosure. But I just added a Cooldrives firewire dual enclosure with 2 Maxtor 300GB disks (yes, the enclosure supports 48-bit LBA ATA-6). I thought everything was fine, had been using them for Ghost 10 backups.

When I tried copying a directory tree containing some DVDs onto one, I started seeing DWFs. I could cancel the copy and re-try, and the DWFs would appear copying the same files. I tried xcopy in a command prompt - DWFs in different files. I could manually copy the same individual files without getting a DWF, but not the directory trees containing them. In the event viewer I coud see that during both successful and unsuccessful copies I was logging bad block errors on the destination drive at rates ranging from every second or two up to 5 per second(!), and only get a DWF after each 300-400 bad block errors. Tried diagnosing the drives (no problems). Reformat (single primary ntfs) and try again, and the same copies would get the DWFs at the same point in the copy.

I just tried the registry tweak from support.microsoft.com/?kbid=330174, and all of the bad block errors and DWFs are gone (without doing anything else). The initial value of SystemPages was 0x0007b000 (503808). Upped it to 0x00ffffff (16777215) and that was it!

Sorry for false previous posting. Problem is partially solved...
Copying from firewire hard disk to system disk works ok.
But copying from the system disk to the firewire hard disk gives the warning about delayed write during paging error.
I measure some improvement with PCILatencyTool on my nforce3 chipset. A (standard) latency from 32 causes more errors than 48.
Will try these http://support.microsoft.com/?kbid=330174 info.

Nevertheless despite the error appears, the large files which were copied to the firewire hard disk seemed to be fine. I did a CRC check, compared them with the original files and did not find a difference.

Sorry for giving you false hope...

Message for w_m0zart. Have you tried running our 1394test.exe applet (available on "Free Utilities" on the top left side of the page). If so, does it fail at 257 sectors? If it does, you have the 128K chip problem inherent in many 1394 bridge chips. Resolutions are available on our 1394 blog. Good luck.

Is it only a Cable problem after all?
Regarding busTRACEs previous question whether I did tried the 1394test.exe. I indeed tried that, but did not find any problem like a buffer size overflow.

As written in my previous posting, I would try the advices in the microsoft article with some test procedure:

Test Procedure
Regarding my test procedure to find the delayed write error: I create a RAR-archive on the external hard disk from a 2.5 GB folder with some wav files. The Archive is created in the same directory as the source files are. For compression I use 'store'. With this option a lot of traffic through the firewire connection is being generated.

microsoft article
http://support.microsoft.com/?kbid=330174
The second item in the article was: You are using a 40-wire connector cable to connect the UDMA drive to the controller instead of the required 80-wire, 40-pin cable.
I indeed used a 40-wire cable, but it was a very short one (only 10 cm in length). I though interference due to adjecent lines would by small. Nevertheless I tried a 80-wire cable instead. And bingo, gone were the errors! I could load the hard disk with another RAR process, but it did not cause any error.
But...
The standard 80-pin IDE cable I tried was about 35 cm in length. It did not fit so well in the enclosure. So I shortened the cable. Strangely enough with this smaller cable the problem reappeared. I am not sure what to do to solve this cable problem, but at least I am on the right track, and convinced software is fine, the bridge can handle 128k. The bridge is b.t.w. from ioi:
http://www.ioi.com.tw/bridgeboards/fw-142as.html

w_ m0zart

Further tests with the long 80-Conductor Cable (35 cm) showed that I had no problems as long as it did not came too close to the switched mode power supply.
The short 80-Conductor Cable (10 cm) gave the delayed write error problems. (And was close to the power supply).
I think that the better performance from the long cable is because it's capacity cancels out some HF-noise. (Or just say the short cable is just too good). To make it work with the short cable as well, I put an RF ferite bead around the 80-Conductor Cable. With this simple mechanic modification my delayed write errors have disappeared. (To be continued...? Let's hope not!)

Picture of this cable:
http://www.nijdam.de/images/RFcable.jpg

Hoping this information helps.

w_m0zart

Hi - I've had a fun few days with this problem as well!

Had 2 * Maxtor 5000XT 250Gb external units running off the firewire port from my Audigy sound card. No problems for 3 years (maybe very occasional delayed write). A few months back the first Maxtor started with loads of corruption so I disconnected it. The second one followed recently. Assumed the disks had died.

Bought myself a couple of WD250JB to put in the maxtor boxes. Put the first one in and windows reported only 128Gb available space. That was the first pain so for anyone looking to replace the disk in their external unit make sure the unit is ATA6 compatible.

So, I buy a couple of nice shiny Icy Box 351 USB/Firewire enclosures (PL-3507 chip). Fit the WD disks, format, chkdsk - all OK. Connect up, copy files, errors all over the place - delayed write, etc until disk disappears from windows altogether. What's more the drive just carries on with the busy light even after restarting the computer.

Tried your test - passed 100%. Tried the MS hotfix - no difference. Updated the ROM on the Icy Box - no difference.

Bought a 3 port firewire PCIcard from Maplin today. It's got the Via 6306 on it so wasn't too hopeful. However, removed the audigy sound card, plugged in the new PCI card, connected IcyBox enclosures.

Have now been copying 3Gb video files, and a folder with 60Gb of music files from main disks to both the IcyBoxes as well as between the 2 IcyBoxes all at the same time. So far not a single error.

Hopefully this will help someone else and many thanks for keeping this page open. It's been very useful.

I just wanted to say thanks... I had a problem with my firewire combo card and an external harddrive.... After connecting with the firewire, after a few hours, the drive would be corrupt. USB 2.0, no problem... Firewire, always unreadable and corrupt. No one had a solution... Not Zonet (combo card), Vantec (enclosure) or Western Digital (Harddrive). After searching on the internet, I found your blog... Used it to get the hotfix from Microsoft... And have been running smoothly ever since! Kudos for your assistance.