- May 19, 2011
- 17,706
- 9,567
- 136
I just 'fixed' a customer's computer, but I'm slightly puzzled about what happened. It's an Alienware 18 laptop, currently owned by (IIRC) a 10-year-old kid, and I was asked to fix it. It wouldn't boot Windows, citing the lack of system32\winload.exe (though one thing that was odd there was that on the blue screen there was no drive letter).
When the computer started up I noticed iRST during the boot sequence so I expected a certain amount of oddness, but anyway. I booted from Win10 setup media, did a quick startup repair, nada, but then I noticed that what was a possible candidate for a Windows installation volume had the usual two Program Files folders but no Windows or Users folder, and the fact that it was called 'New Volume' made me think it was possibly a secondary drive (750GB HDD), but diskpart wasn't showing any other viable partitions for a Windows installation.
I went into iRST config (photo below of configuration screen), and was even more puzzled. A Haswell-era laptop I would have thought would have RAID drivers built into a recent build of Win10, but given how I could already see that 10GB partition (TBH I didn't look into it because 10GB isn't enough for a Win10 install), logically Windows could already see the contents of that mSATA drive that's listed, and even more puzzling, its 64GB partition is big enough for a plain Win10 install but it shows up here as disabled. I also tried feeding Windows setup the correct iRST driver for the laptop but diskpart didn't show up any extra drives/partitions.
The 750GB drive had enough partitions on it that it could conceivably have hosted a Win10 install, so I did a full chkdsk on that drive and figured that the Windows install must either have been borked by a kid to such an insane degree that this happened or whatever other explanation for why Windows installs go kaboom. I also figured that when I was ready I'd do a test install with a separate disk and see whether the machine has any other issues that could explain the non-zero amount of squirrels in this situation.
The customer agreed to a fresh Windows install (I tried to convince them to get an SSD in there but they said no), and once I backed up some Steam data off that HDD I decided that it would be best to get rid of the pointless iRST config and just install onto the HDD in the interests of 'keep it simple'. I went into the BIOS, switched it from Intel RAID to AHCI, it warned me that I could lose everything, sure, why not. I then went to boot into Windows setup, pulled up the 'which device do you want to boot from this time' screen, and there was a new entry on it: 'mSATA'. Why the hell not I thought, and told it to boot from it. Windows then booted absolutely fine with the customer's old Windows install.
So my guess as to what's happened is that the laptop originally shipped with this iRST config, someone else then switched from RAID to AHCI, installed WIndows on mSATA but didn't erase the iRST config, so there's some tiny partition on the mSATA drive with the iRST config that's been doing nothing as well as being completely invalid ever since (The Windows C drive doesn't match with the iRST partition config, it's basically the size of the mSATA drive), until something recent and strange happened, maybe the kid switched the configuration back to RAID and then panicked?
Another theory I've just come up with while writing this is that the customer was talking about the laptop battery not working any more so they disconnected it. My next guess is that the CMOS battery has died (I noticed the CMOS clock had reset) and it went back to its default RAID config. I bet that if I disconnect this laptop from the mains, it'll lose the BIOS config and the problem will reoccur.
- edit - I just shut Windows down, disconnected the mains, attempted to switch the computer on without a battery in an attempt to drain residual voltage, then reconnected the mains and the PC boots Windows fine. I think my second theory may still be a bit shaky.
Any other theories?
When the computer started up I noticed iRST during the boot sequence so I expected a certain amount of oddness, but anyway. I booted from Win10 setup media, did a quick startup repair, nada, but then I noticed that what was a possible candidate for a Windows installation volume had the usual two Program Files folders but no Windows or Users folder, and the fact that it was called 'New Volume' made me think it was possibly a secondary drive (750GB HDD), but diskpart wasn't showing any other viable partitions for a Windows installation.
I went into iRST config (photo below of configuration screen), and was even more puzzled. A Haswell-era laptop I would have thought would have RAID drivers built into a recent build of Win10, but given how I could already see that 10GB partition (TBH I didn't look into it because 10GB isn't enough for a Win10 install), logically Windows could already see the contents of that mSATA drive that's listed, and even more puzzling, its 64GB partition is big enough for a plain Win10 install but it shows up here as disabled. I also tried feeding Windows setup the correct iRST driver for the laptop but diskpart didn't show up any extra drives/partitions.
The 750GB drive had enough partitions on it that it could conceivably have hosted a Win10 install, so I did a full chkdsk on that drive and figured that the Windows install must either have been borked by a kid to such an insane degree that this happened or whatever other explanation for why Windows installs go kaboom. I also figured that when I was ready I'd do a test install with a separate disk and see whether the machine has any other issues that could explain the non-zero amount of squirrels in this situation.
The customer agreed to a fresh Windows install (I tried to convince them to get an SSD in there but they said no), and once I backed up some Steam data off that HDD I decided that it would be best to get rid of the pointless iRST config and just install onto the HDD in the interests of 'keep it simple'. I went into the BIOS, switched it from Intel RAID to AHCI, it warned me that I could lose everything, sure, why not. I then went to boot into Windows setup, pulled up the 'which device do you want to boot from this time' screen, and there was a new entry on it: 'mSATA'. Why the hell not I thought, and told it to boot from it. Windows then booted absolutely fine with the customer's old Windows install.
So my guess as to what's happened is that the laptop originally shipped with this iRST config, someone else then switched from RAID to AHCI, installed WIndows on mSATA but didn't erase the iRST config, so there's some tiny partition on the mSATA drive with the iRST config that's been doing nothing as well as being completely invalid ever since (The Windows C drive doesn't match with the iRST partition config, it's basically the size of the mSATA drive), until something recent and strange happened, maybe the kid switched the configuration back to RAID and then panicked?
Another theory I've just come up with while writing this is that the customer was talking about the laptop battery not working any more so they disconnected it. My next guess is that the CMOS battery has died (I noticed the CMOS clock had reset) and it went back to its default RAID config. I bet that if I disconnect this laptop from the mains, it'll lose the BIOS config and the problem will reoccur.
- edit - I just shut Windows down, disconnected the mains, attempted to switch the computer on without a battery in an attempt to drain residual voltage, then reconnected the mains and the PC boots Windows fine. I think my second theory may still be a bit shaky.
Any other theories?
Last edited:
Facebook
Twitter