System Crashes When Copying to External HD

Apologies if this specific issue has been covered in another thread. I posted in a different thread but the issue was not entirely similar.

I am now using build 7600 but had the same issue in beta and rc. Whenever I connect an external drive to copy or back-up large folders, my system freezes almost immediately. I have 2ghz AMD x64 with 4gb ram. In Vista, this was never a problem. I could copy many gigs of media-data with five or six instances running at the same time, reduce the "copying" windows and continue running multiple apps with no performance issue.

In all versions of 7 to this point, If even one other window is open-and even if I am doing nothing else, complete freeze. Mouse and keyboard do not respond and even if I can get CPR to work, it takes several min to get to task manager and even longer to end the process string if I can even do it at all. Most times, I end up doing a forced shut-down.

On the occasions I can cancel the process, my computer response is slow, sporadic, repeated cpu max-out and barely functions. The only way to get it back to normal is a full re-start. Drag and drop is the worst followed by copy and paste and then robocopy though all eventually cause freeze up. Every once in a great while, I can get a large folder to copy as long as it is the only thing I am doing, shut off all non-critical services and close my network connection. Small files are no problem though there is no magic size that seems to cause the problem. A copy function of as little as 40mb has caused the freeze-up.

I have seen on other sites that there have been unpublished updates leaked that change the hardware abstraction layer from 16385 to 16399 along with explorer, iexplorer, etc. build strings. Interestingly enough, the free app "blue screen review" reports these issues as BSOD caused by the hal.dll file. Though I dont actually get a blue screen, it does grind my system to a hault. I am wondering if this newer hal 16399 could solve this but since it hasnt been officially published by ms update or catalog, am reluctant to try it. Has anyone heard or tested these particular updates? Could this be the real problem? A bad hal driver?

This had been the only real problem I have had with 7. Other than that, it rocks. Some troubleshooting steps I have taken are:
1-shut down aero and as many process strings as possible to see if the performance improved. System still crashes though it does manage to copy some info first.
2-Disabled AV software prior to copying
3-Ran every test I could think of on all drives including SMART but just got a brand new WD passport-same issue. Even Win back-up(used it for the image file) fails the first time everytime though will eventually finish the backup after the 2nd try.
4-Can copy large media files one at a time but with over 400gb of movies and 100 of music, no time. Hopefully this is some kind of glitch??
5-Tested this process with the same drives on other machines and no issues though I have not had the opportunity to test on another pc with 7-not available to me at this point.
6-Checked for and installed all win7 compatible drivers for the external drives, no change.

Is anyone else having this specific issue? Known bug? Possible fix? Thanks in advance for reading my small novel. Any help you can provide would be greatly appreciated. As I said, other than this particular problem, I am absolutely loving 7. But on the same machine, same hardware, cpu, etc under Vista, no issue.

You should run workshops on "How to describe your issue and make it sound like fun to troubleshoot". Have rep :)

Did you have a chance to test safe mode, as discussed?

What exactly are these "external drives"? USB sticks? HDDs connected via USB? HDDs connected via 1394 (firewire) or eSATA? Networked drives? If you haven't already done so, it would be very useful to verify whether the symptom is confined to one or more of those device classes, or whether it includes all of them - even a lowly $4.99 256MB USB stick.

Which process do you find yourself needing to end-task because it's consuming processor time? For example, if you're copying via Robocopy, does Robocopy become the offending process which you're aiming to kill if you want your responsiveness back?

Does this machine have a functioning serial (RS232) port, or 1394? If so, do you have another box close by which you could link to this one via a cable? (In a "last resort" situation, that type of setup can be used for some in-depth troubleshooting.)

I'm unclear on whether you've observed this issue first-thing-after-a-reinstall of the OS? In other words, was the symptom under Win7 always there, even before you apply any updates or install AV utilities, apps... ?

The HAL is literally one of the lowest-level and most important parts of the OS, so it's impractical at this juncture to speculate as to whether the HAL is somehow the culprit. It's definitely involved (in everything), so it could potentially be in need of an update, but running an incompatible HAL can be anything from frustrating to unworkable. For now, I'd suggest you don't experiment with HALs.

I'll try to make some more practical suggestions once I have a better grasp of the scope of the problem.

I am having the same problem... I think mine are due to faulty nforce chipset driver... but my keyboard and mouse are still usable...

another thread

From another thread... another user installed USB 2.0 expansion card to his PCI slot and he can copy large files from internal to external USB devices.

From reading the posts in the forum fendytan, maybe it is a chipset problem. I've got Geforce 7150/nforce 630 combo integrated graphics board for laptops and as far as I can tell, have the latest drivers. Maybe nvidia is the place to direct this issue?

Fendytan-what chipset are you using? You said yours was nvidia too right?

tmp said:

From reading the posts in the forum fendytan, maybe it is a chipset problem. I've got Geforce 7150/nforce 630 combo integrated graphics board for laptops and as far as I can tell, have the latest drivers. Maybe nvidia is the place to direct this issue?

Fendytan-what chipset are you using? You said yours was nvidia too right?

Based on the latest info, I think you'd do well to update the chipset drivers and flash the BIOS. Given some of the things you mentioned and the fact that it happens on a clean build of Win7, it looks likely that there's an incompatibility between the OS and your current chipset/disk controllers which cannot be rectified by tweaking settings.

Interrupts are a way for a hardware device to get the OS's attention in response to some sort of time-critical event. For example, when the user presses a key, the keyboard issues an interrupt which makes the OS stop whatever it was doing for a (very) short while, deal with the implications of the keystroke, and then resume its earlier activity. Same with disks. When the disk controller has copied another unit-worth of data into a designated location for the OS to move, it issues an interrupt to let the OS know that there's something it needs to do. A large file copy is therefore a series of a squillion interrupts as each small chunk is copied by the HDD/controller into a buffer, then moved elsewhere by the OS.

One of the interesting things about interrupts is that they happen in what's called an "arbitrary thread context", which is a fancy way of saying that the OS temporarily hijacks whatever process/thread is running at the time to deal with the interrupt. In other words, if the HDD/controller happens to interrupt while calc.exe is running, that small chunk of processor utilisation will be "charged" to the Calculator, even though it had nothing to do with the file copy. Win7 is a bit better in this regard because at least it tells you that the processor utilisation stems from a high rate of interrupts, but because of the "arbitrary" nature of the process context there's no process name associated with that activity in Task Manager, as you've noticed.

When a hardware device goes a bit bonkers, sometimes it starts generating interrupts at such a high rate that it effectively pesters the OS to the point where it cannot do much else. It may look like some hapless process is consuming that processor time, but end-tasking the process doesn't help because the interrupt utilisation simply gets attributed to the next one to come along. I think that's exactly what's happening in your case, except the HDD controller may not be ga-ga... it's just got a fundamental low-level incompatibility with Win7, for reasons that I can only guess at.

If the machine has firewire (1394) or eSATA ports, it would be very interesting to see what happens if you plug in external drives of those varieties, borrowed if necessary. My guess is that the problem probably wouldn't occur, given the somewhat different mix of hardware and drivers involved.

I am not aware of any HAL updates for RTM Win7 at this point, but I'm not well informed on that topic. At this stage, my suggestion would be to go for every single update you can find (from the manufacturer/developer, not from a 3rd-party), and to cross your fingers that will do the trick. The fact that it also happens in safe mode, with multiple completely "clean" OS installations, and with multiple drives, pretty much rules out something that could be fixed with a tick in a tickbox.

Lastly, you've tried all of the USB ports on the machine and they all do this, right?

H2SO4, Thanks for the explanation. It helped me understand what has been going on much better and I can see why a simple copy process is basically overloading the cpu yet the memory usage stays at about 30%. I have tried all the ports. I spoke with someone at Nvidia today. They suggested using a win7 64 bit compatible driver but the one they suggested was for desktops. I have Geforce 7150m/630n and the desktop version is Geforce 7150m/630i. My integrated card was not listed as supported so I inquired as to whether or not it would be compatible and am waiting to hear back. There is no Win7 driver yet for my specific board/card. HP of course, suggests only using the drivers listed on their site and they number them differently so it's a bit tricky trying to figure out exactly which driver I have. I know they only post the ones they've tested, including the Bios update(released 3/09 for my particular system) but other drivers like the chipset are listed on HP as driver number 13.11 and the latest on nvidia is 15.37. How far behing can they be?? It seems nobody at HP is really concentrating on a 2007 machine, must be too far out of date I guess? Too bad for them I'm still under warranty though they refuse to offer any support on Win 7 until Oct 22 though my copy is legal. And of course technet and msdn are of no help at all because they want me to forward concerns to HP. The old pass the buck game. I need to do some research and try and see if there is a newer bios update though it's hard to track down outside the HP site. The chipset and bios are not listed in device manager so again, for a novice like me, hard to find exactly which version of the chipset driver I have though I do believe it is from the HP dl site. I will see if I can find a firewire device and give it a try. I will post again when I get more info from nvidia. Thanks for all your help and if you have any further ideas, it'd be great to hear them.

Well, I crossed my fingers and went ahead with the recommended driver from nvidia. It is meant for the desktop version but I installed it anyway and my back-up went smooth and copying a large file-about 20GB-just to check, never put my cpu above 15% on it's own. I guess for now, problem solved. If anyone has a Geforce/nforce integrated card, the chipset driver I used was #15.37 for windows 7 x64. Thanks for all the help guys!!