The driver detected a controller error on \Device\Harddisk

Discussion in 'other software & services' started by sansemiano, Jan 6, 2007.

Thread Status:
Not open for further replies.
  1. sansemiano

    sansemiano Registered Member

    Joined:
    Jun 4, 2006
    Posts:
    30
    Recently my rig has begun to spit out in the system event-log the following messages:

    "The driver detected a controller error on \Device\Harddisk1\D."

    or

    "The driver detected a controller error on \Device\Harddisk0\D."

    All this with eventID: 11.

    Everything works fine; checkdisk does not find anything irregular. Sata-cables are fixed. Temps are not too high.

    The only application that is bothered by this is Acronis True Image Home. When the system is in this state it's impossible to make an image. True Image just stops with an error message saying something about 'error writing file' (error 0x40003). At the same time it's perfectly possible to write a simple txt-file with Notepad on the same partition True Image wants to write it's image.

    Sometimes a reboot helps to solve it for a while. Restoring an older image did help for a while. Re-installing the nVidia storage drivers did not help. Switching of the AI NOS overclocking system of the Asus A8N-SLI Premium motherboard does not help.

    Un-installing the nVidia display driver does help. After that the error messages in the event log have gone and True Image works fine every time.

    Under Windows Vista RC1 everything works fine. No error messages in the event log.

    Anyone having any idea what is going here and how to get rid of it?
     
  2. sansemiano

    sansemiano Registered Member

    Joined:
    Jun 4, 2006
    Posts:
    30
    removed the nvidia ide drivers. that made the event id:11 errors disappear. the system is now using the windows ide drivers.

    anyone know why this is? something corrupt in the registry maybe?

    it worked fine with those nvidia ide drivers for over a year. on another pc it still does.
     
  3. sansemiano

    sansemiano Registered Member

    Joined:
    Jun 4, 2006
    Posts:
    30
    re-installed the nvidia ide-drivers and the display driver.

    the problem with the huge amount of event id:11 messages maybe has to do with vmware running or not. at the moment vmware starts the event log sometimes is flooded with dozens of these messages.

    maybe the solution for ati is to stop vmware before making an image.
     
    Last edited: Jan 7, 2007
  4. Ice_Czar

    Ice_Czar Registered Member

    Joined:
    May 21, 2002
    Posts:
    696
    Location:
    Boulder Colorado
    http://www.lostcircuits.com/hdd/hdd5/

    Id say your guess that this is a driver issue is likely correct especially when factoring in the three variables youve mentioned.

    Normal Optimized Chipset busmastering
    vs
    Low level imaging (TI)
    vs
    Virtualization

    further its a pretty opaque area when it comes to fixing it yourself (provided your not a programmer) your conclusion seems logical especially if youve tested it.

    Ideally Id try to restore the "optimized" busmaster\chipset drivers over the "reference" Microsoft busmaster drivers for day to day employment and see if just taking virtualization offline is enough to allow you to backup reliably

    on the hardware front its been a long time since anyone has had to manually assign IRQs, but most home users are also unaware of exactly how PIRQs are handled at the hardware level, something few desktop mobos document but which is almost always documented in a workstation or server mobo

    you might try to find your PIRQ table and switch your HDDs priority (if possible, with say a PCI card in the right slot vs a system level USB PIRQ, you didnt mention physical specifics) inorder to workaround the issue.

    review this for the best tutorial I know of on IRQs & PIRQ Routing
    http://web.archive.org/web/20050907201409/http://www.sudhian.com/showfaqs.cfm?fid=2&fcid=26
    obviously the specific examples apply to the chipset under discussion

    excerpt
    in my experience its generally better to try to workout this stuff within ACPI \ APIC than to disable it in the BIOS and reinstall with a different HAL just to manually assign IRQs and considering the potential driver variables with virtualization Id really dismiss that option as raised in the article.
     
    Last edited: Jan 7, 2007
  5. sansemiano

    sansemiano Registered Member

    Joined:
    Jun 4, 2006
    Posts:
    30
    thanks for the elaborate information. tried to give the sata controllers more time with pci latency tool, but to no avail. btw, nothing has changed in the way the irq's are used on my xp-rig. it's the same as before all this **** started to emerge.

    i also installed ati under vista rc1 and there it works fine. with the same chipset, the same power supply, the same cpu, the same memory, etc, etc.

    it has also not to do with vmware running or not.

    does anyone know why the ati problem is gone after un-installing the nvidia display driver?
     
    Last edited: Jan 8, 2007
  6. Ice_Czar

    Ice_Czar Registered Member

    Joined:
    May 21, 2002
    Posts:
    696
    Location:
    Boulder Colorado
    not specifically
    but it does sound like a conflict in the drivers


    some other things you could try that would rule out possible contributing factors on the hardware level.

    One
    ATA (AT Attachment be it parallel or serial) employs CRC (Cyclic redundancy check) to insure data integrity. But unshielded cables act like antennas. Generally speaking, the longer you make 'em, the more energy they can pick up from their environment. And if their environment happens to be close proximity to a power cable for some length or a ground plane (case side) that can cause more noise in the data transmission line. When SATA was first introduced some of the cables lacked enough shielding and that caused some issues. While the standard was far better than PATA (IDE) it was still an issue.
    (some of the technical reasons and differences below)

    you can reroute your cables away from power cables even a short distance make a big difference (Electromagnetic fields obey the inverse square law, twice the distance four times less the EMI) Reducing the noise the protocol has to shout through may help. That the OS is detecting CRC or timeouts is likely why your getting these warnings, how its dealing with it via SATA is fundamentally different I gather than what was typical in PATA\ATAPI

    IDE ATA and ATAPI Disks Use PIO Mode After Multiple Time-Out or CRC Errors Occur

    you could also swap out your cables if you have spares
    again things that might make for less noise in the line and allow the drivers you do have to work with a batter chance?

    Two

    System timing
    you havent mentioned your specific board, or if for instance your using performance RAM settings. These could be another contributing factor
    especially any changes to the tRAS from the defualt is a bad no no. And loosing up the RAM timings in general may help overall. (read back em down to stock if youve bumped them, consider dropping them if its "performance RAM" & if this is unfamiliar territory leave it alone)

    Third

    Drivers
    Check if there is any BIOS revision that is applicable, try both older and newer chipset drivers. Try reloading your video drivers after a clean uninstall, sometimes as strange as it sounds just the order of installation of drivers makes a difference.
     
    Last edited: Jan 8, 2007
  7. sansemiano

    sansemiano Registered Member

    Joined:
    Jun 4, 2006
    Posts:
    30
    1 - i exchanged the sata-cables for other ones, but it made not any difference. was unlikely, cause the same cables work fine under vista rc1;

    2 - i am indeed using a little tightened memory timings (2.5-3-3-6), but have been doing that from the beginning with this rig. has not ever been a problem. so why now?

    3 - my rig is built upon an asus a8n-sli premium and it's running the latest beta bios 1302. this bios is in use for almost a year and the system has been operating fine with it.

    something to add:

    before all this ati/eventid:11 mishap started the system has been bothered for quite some time with a kind of 'self-un-installing' of the nvidia display driver. after so many re-boots of the system the display driver was no longer functional and windows had reverted to it's default driver.

    i think that 'kick-the-nvidia-display-driver-out-of-my-system'-behavior started after an update of the windows installer (last summer) by windows update, but i'm not sure...
     
  8. Ice_Czar

    Ice_Czar Registered Member

    Joined:
    May 21, 2002
    Posts:
    696
    Location:
    Boulder Colorado
    yeh thats sounding more and more like some code incompatibility
    hate to say this but what Ive generally seen done with these issue is starting from scratch inorder to play around with driver install orders and possible conflicting aps\patches. (simplify and isolate variables)

    a true pain in the butt

    Id try Driver Cleaner first and all the latest drivers on the current install
    but if that doesnt do it, Id probably look to start fresh and isolate
    (as well as run a few rounds of diagnostics, drives, memory ect sometimes the simple stuff is overlooked make sure the hardware passes with flying colors)
     
  9. SYS 64738

    SYS 64738 Registered Member

    Joined:
    Apr 29, 2006
    Posts:
    130
    Recently, i had the same kind of Error on my Mum's new Computer (AMD Athlon™ 64 3800+ (Socket AM2) on MSI K9N4 Ultra-F, NVIDIA® nForce 500 Ultra Chipset, WinXP SP2). On system boot it took several minutes for the logon screen to appear, especially if it is the first boot after some hours. Upon reboot sometimes everything was normal. I noticed the same entries in the system event-log. Usually after an entry of "nvata" there are several (~10 - 15) entries with "The driver detected a controller error on \Device\Harddisk1\D."
    Despite of the fact that this error messages were made after the "nvata" entry, the recorded time were about three minutes before the "nvata" entry.
    The issue was fixed for me by installation of a processor driver provided on the MSI motherboard driver CD. I found it in a folder named AMD CPU Tool (http://www.msi.com.tw/program/support/software/swr/spt_swr_detail.php?UID=758&kind=1)
    with a file called PN_1_3_2.exe. Obviously it is a driver provided by AMD and it is part of the "Mobile AMD Athlon™ 64 Processor Driver for Windows XP and Windows Server 2003 Version (x86 and x64 exe) 1.3.2.16" package.
    Of course i do not know if your system is similar to mine, but maybe this could be of some help for you...
    Good luck.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.