Jump to content











Photo

Windows 8 boot + drivers -- Some notes

windows-slow-boot drivers dma

  • Please log in to reply
11 replies to this topic

#1 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 14 November 2014 - 06:14 AM

I have learned a few things in my recent encounter with Windows drivers and booting, and would like to share it for others, as well as further learning.My setup : I have an MSI P45 Platinum, which contains 23 storage controllers
  • One controller is a part of the Intel SouthBridge ICH10R,
  • One JMB363 supporting 1 PATA port + 2 SATA ports
  • One JMB362 (supporting 2 SATA ports)/JMB361 (1 SATA port + 1 PATA port), in which only 1 eSATA port is used. Not sure which exact controller.
I have disabled (2) in the firmware configuration. I have a 360GB SATA HDD fitted inside a Transcend Storejet 35 Ultra. This features an eSATA output, which is connected to the eSATA port of the JMicron controller. My installation of Windows 8.1 is stored on this external HDD, which seems to be fairly unique. Unless otherwise mentioned, all these issues were encountered in Windows 8.

A 1TB HDD connected to the Intel SATA ports hosts a Windows 7 installation, which, till date, has been no trouble at all.
 
My issues :
  • Very Slow boot : Normal boot is very slow, even loading the boot menu (F8) takes a heck of a long time, with a continuous HDD LED glow. I always wondered why that must be the case.
  • Frequent corruption when dual booting : This was a long and annoying set of troubling problems that kept recurring, with one windows, then the other, though the culprit was definitely something on Windows 8. Witness : http://www.sevenforu...0x000000b6.html
  • Extremely SLOW Windows 8 "Fast Startup" : What was a moderately slow annoying delay becomes a 10-minute frustrating wait when "Fast startup" AKA Hybrid boot is enabled in Windows 8. The circling dots slow to a 1FPS crawl! Not surprisingly the same thing happens when using Hibernate.
  • Unavailability of HDD SMART info : SMART was not available for the external HDD, which was puzzling, because the other Windows reads it just fine.
What I figured out when I solved some of these issues comes in my next post.
 
(There might be a delay of a few hours if some other work comes up though.)


#2 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 14 November 2014 - 06:35 AM

I started trying to attack issues 1&3... Though I didn't get anywhere just yet, I learned a lot of background info.

 

First, I looked at the drivers. When windows is initially installed, it recognized the JMB36x as a "Standard Dual Channel PCI IDE Controller", along with "ATA Channel 0/1". Needless to say, I didn't like it : I wanted full SATA AHCI functionality. So I was happy to find a driver on the MSI site, and then an updated version on the JMicron site... I installed it, and boom! all mention of IDE and ATA vanished. Instead, I found an entry in the "Storage Controllers" section titled "JMicron JMB36x Controller".. I was happy that I was using the correct, customised drivers instead of Microsoft's generic "crap" drivers.

 

But it hadn't solved the problem. I had since reverted to a stored system image a couple of times, and so had to reinstall, and had forgotten that I had gotten no tangible benefit.

 

At this time I discovered issue 4 happens ONLY when the JMicron driver is installed, and ONLY when using Seagate SeaTools. The issue should have been closed, but I'm a bit obsessive compulsive, and I NEEDED to know what was wrong.

 

Looking closer, I found my drive under the heading "SCSI-FC-SAS"! Attached File  seatoolsscsi.PNG   40.89KB   0 downloads

 

So that's why it was not showing SMART info : it thought it wasn't an ATA drive at all! Other programs seemed to do fine since they might have asked the disk despite an indication of a different storage controller.

 

Then I looked at the actual driver that were installed : jraid.sys, and under SCSIAdapter. That made some sense, but more was to come.

 

(Mods, please give me permission to edit after an extended period, want to add some pictures.)



#3 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 14 November 2014 - 06:18 PM

It turns out that JMicron has implemented its controller as an SCSI device in its driver, and I could not find an AHCI driver, even modded, hacked, etc... EDIT : see link at end. Also : http://vip.asus.com/...SLanguage=en-us
 
Further proof that the disk was recognized as a SCSI device came directly from device manager : Attached File  jraid.PNG   47.36KB   0 downloads
 
Having dropped that issue for the time-being, I now wanted to get the boot speed back to normal. So I tried to remove the jraid driver.... no-go! It was recognized as a system driver for the boot drive, so it wasn't going to remove it... 
 
Being not very afraid of consequences, I "updated" the storage controller with the "Standard SATA AHCI Controller"... It needed a restart, and thought that it would come up as a problem next boot, and then would fix itself.
 
That's of course, not what happened. It BSODed with INACCESSIBLE_BOOT_DEVICE. Then I tried the usual litany of solutions : safe mode, startup repair, restarts, sfc, dism, etc... None of them worked, and frankly, I didn't expect them to. 
 
Seeing no choice other than to get my hands dirty, I then recalled that the CriticalDeviceDatabase registry key is used by winload.exe (and ntoskrnl.exe). But when I tried to find the key, I realized that Windows 8 no longer has it! Instead in its place, is the DriverDatabase key. But digging in, I saw nothing like a list of devices critical for boot. I suspect it does not exist anymore.
 
Instead, I mounted the system registry hive of a known-good system image. Then I searched for "Jmicron" and came up with a key in Class. This lists the jraid driver, whose complete description can be found in DriverPackages. Searching for the same PCI device ID info (aside : a criticism of the registry for not using a proper database for this : http://rwmj.wordpres...ks-technically/) in the current system revealed the node having the AHCI controller attached. I simply deleted the node and ..... 
.....it booted up!
 
So questions/answers :
 
1) Is there truly no CDDB in Windows 8? If yes, then can I delete ALL the driver nodes associated with hardware devices, and still have windows boot up properly?
 
2) Why does everyone prefer to write SCSI drivers instead of plain old AHCI drivers? or is AHCI not "plain"? Even Olof Lagerkvist in Arsenal Mounter uses a(an?) SCSI driver, so there must be something about it.
 
REVISED : Additional info http://blog.stuffedc...card-ahci-mode/


#4 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1334 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 14 November 2014 - 10:16 PM

2) Why does everyone prefer to write SCSI drivers instead of plain old AHCI drivers? or is AHCI not "plain"? Even Olof Lagerkvist in Arsenal Mounter uses a(an?) SCSI driver, so there must be something about it.

 

There are several reasons behind this. I could write a lengthy post with historical references to a major storage stack design change that was made between the NT 3.51 and NT 4.0 kernels, but I think I skip the early history and start from the point in history when Server 2003 with StorPort architecture was introduced. :)

 

Anyway, a storage port driver is quite complex. Therefore, to make life a lot easier, Windows provides a miniport architecture where Windows itself provides the port driver and leave only the adapter-specific, hardware related, things like physical addresses, command queues etc for manufacturers to supply in a miniport driver. The port driver also provides a large set of support routines to make things easier for the miniport.

 

There are basically storage port/miniport stacks available for IDE and SCSI, called ataport.sys and scsiport.sys. Miniport drivers are written for use with one of those. They are both very limited for historical reasons though, queuing, throughput performance and several other things inherit limitations from the 90's, pretty much. Also, both of them only support physical hardware and load a miniport only in response to allocated physical hardware resources. This means that purely virtual adapters are not supported. There are workarounds for scsiport.sys though such as claiming non-used non-plug-and-play ISA bus resources and provide a miniport driver for this, but it involves a whole lot more of tricky things like being able to complete requests without actual hardware interrupts and similar.

 

To address the performance and flexibility issues and provide a more generic port architecture made for modern high-performance storage devices and to prepare for software-only virtual adapters, Microsoft introduced storport.sys in Server 2003. It is basically a rewrite of the old scsiport.sys but for plug-and-play only and without certain limitations in the basic design. From that point, miniports where recommended to target the storport.sys port driver instead of ataport.sys or scsiport.sys. Because storport.sys is a SCSI port driver, all adapters managed by miniports written for storport.sys will show as SCSI adapter devices in Device Management.

 

That's it, pretty much.

:cheers:



#5 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 16 November 2014 - 11:12 AM

Thanks for the great info, I might not have got it otherwise :)

 

This explains why ALL virtual drive programs use an SCSI virtual drive, but it does not explain why a physical driver for a real physical hardware device is anything different from its true functionality : I mean, the controller is connected using SATA, why would it pretend to be SCSI?

 

Intel's SATA controller does not seem to have this problem.



#6 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 16 November 2014 - 11:18 AM

The next part of my adventure was the boot time reduction.... Simply put, there was an option to enable "PCI IDE Bus Mastering" in an options menu in my BIOS. I had originally disabled it, thinking it was not applicable to SATA controllers... But later I learned that it was using the term IDE in its original sense which is still applicable to modern computers : Integrated Drive Electronics. That is, the drive has its own controller, as opposed to VERY old drives which were much more "dumb".

 

More importantly, it means that the device can do data operations to memory all on its own (DMA)..... Disabling Bus Mastering meant that the bootloader was reading data from disk using Programmed Input/Output (PIO), which makes a lot of sense if you think about it : VERY busy HDD LED, and VERY slow data transfer, since the processor has to manage the transfer.



#7 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1334 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 16 November 2014 - 12:17 PM

Thanks for the great info, I might not have got it otherwise :)
 
This explains why ALL virtual drive programs use an SCSI virtual drive, but it does not explain why a physical driver for a real physical hardware device is anything different from its true functionality : I mean, the controller is connected using SATA, why would it pretend to be SCSI?


Simply to make it use a plain and easy architecture for which it is a lot easier to write an efficient driver. It means that in Windows, it is easier to provide a high-performance storport.sys based miniport driver.
 

Intel's SATA controller does not seem to have this problem.


It's not a "problem" really, it's about design choices based on priorities like architecture/driver simplicity vs complexity/compatibility. It is easier with SCSI design to make a high-performance architecture and driver. It would be possible with more compatible ATA architecture too, but it will be a more complicated design and a lot more complex drivers. Look at how many updates and fixes and also reports about faulty Intel SATA drivers there are in various forums, for instance.

#8 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 17 November 2014 - 05:22 AM

So you're saying that its easier to write an SCSI-based driver for a SATA controller than a SATA-driver? 

 

What are the consequences of this? Will SATA features like NCQ, port multipliers, etc.. be supported? If yes, how?



#9 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 17 November 2014 - 05:25 AM

I wanted to get pictures of the exact key which I deleted to recover from INACCESSIBLE_BOOT_DEVICE, but I could not trace it, and I bumbled through multiple steps to finally get my computer working again, after intentionally changing the driver to the Standard PCI IDE controller... So I won't be digging in there till I have backed up everything kept failsafes of the registry.

 

Anyone here can give a small description of how the registry holds hardware info (for boot and otherwise devices) ? It would be very helpful indeed...



#10 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1334 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 17 November 2014 - 03:04 PM

So you're saying that its easier to write an SCSI-based driver for a SATA controller than a SATA-driver? 
 
What are the consequences of this? Will SATA features like NCQ, port multipliers, etc.. be supported? If yes, how?


I don't have all the details right now, but storport supports most things needed for implementing a SATA AHCI driver. One notable exception though is TRIM (aka UNMAP in SCSI world), which was not supported by storport until Windows 8. There were more or less easily implemented possible workarounds though, like filtering above storport to intercept TRIM requests from higher-level drivers, but it was not directly supported.

Some googling gave this example of a StorPort based SATA AHCI miniport:
http://joyasystems.c...++/src/common.c
You could see there how it handles various SCSI requests and passes ATA requests down to the device.
 

I wanted to get pictures of the exact key which I deleted to recover from INACCESSIBLE_BOOT_DEVICE, but I could not trace it, and I bumbled through multiple steps to finally get my computer working again, after intentionally changing the driver to the Standard PCI IDE controller... So I won't be digging in there till I have backed up everything kept failsafes of the registry.
 
Anyone here can give a small description of how the registry holds hardware info (for boot and otherwise devices) ? It would be very helpful indeed...


Well, I would certainly like to know more about this too. Right now I have a problem with my Windows To Go 8.1 USB flash disk. When I use it on my laptop I would very much like to use the Intel AHCI driver for accessing the internal hard drive because it would give better performance than the default SATA driver in Windows 8.1. But when I upgrade the driver to Intel's own driver (ataport based miniport, not storport), then my Windows To Go would not boot anymore on that laptop... I have not a single clue why. The driver for the onboard chipset should not interfere with booting from a USB disk? I have tried to run under a debugger but cannot see any exceptions or strange requests/responses to or from the Intel driver during startup either. It simply causes an INACCESSIBLE_BOOT_DEVICE as soon as it is loaded. If I disable the driver completely in registry and/or remove the IaStor driver files, it boots up just perfectly.

This does not happen with another machine with a storport based miniport for the internal SATA AHCI controller. That driver does not interfere with booting the USB flash disk.

Ideally, I would like my Windows To Go to not even attempt to touch the internal controller during boot time. It is enough to load drivers for such devices later on.

#11 cdob

cdob

    Gold Member

  • Expert
  • 1315 posts

Posted 17 November 2014 - 05:10 PM

Anyone here can give a small description of how the registry holds hardware info (for boot and otherwise devices) ?

There is a new layout at Windows 8
http://answers.micro...14-7873924f2a3d

And there is StartOverride: start=0 is disabled
http://reboot.pro/to...ng/#entry181384

#12 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 198 posts
  • Location:Bangalore
  •  
    India

Posted 19 November 2014 - 11:10 AM

Interesting links. Here is a very related set of info : https://social.msdn....82012?forum=wdk







Also tagged with one or more of these keywords: windows-slow-boot, drivers, dma

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users