Randomlyish-occurring BSOD after installing hardware from another PC.

...Er.. Didn't I tell you twice that I can't update this one manually, because the software provided by the vendor that makes it tells me it won't let me install it? DriverEasy was suggested to get around this, and as I stated in a previous post, things seem to be improving already.

Also, the advice you're giving me (and MSClin) seems very contradictory with yourself. "Don't update it'll make things worse! OH GOSH REVERT THE UPDATES! Please update your drivers now." -- Would you mind if we rebooted our conversation and started over from a more clear point, and preferably with more technical details instead of short little responses that make me feel like you're assuming I can't work with a computer at a basic level?

It would be better to not revert the drivers. As you said, if you can't install the driver manually, the best way would be a program (or someone who can install the driver for you).

@axe0: I know that programs are not a good way to update drivers, but in case that someone can't install driver manually or he isn't sure that he download the right driver or even downloaded a driver, a program would be good. The chance to find a bug in a driver updating program when it has more than a million users is so low that you should consider yourself lucky if you do find a bug.

axe0 said:

Your system may feel like it's improving now, but what about the next periods? It happens frequently that the next periods result in trouble thanks to the drivers from such programs.

Would you mind explaining how that happens? :)

Though for the thing you said to me (updating drivers in BSOD will just make it worse), this may depend. I experienced many BSODs and in most of the times it was drivers. So, sometimes updating them fix the issue, but in other - old drivers would fix it. Updating or reverting driver to old version can't make anything worse than how it is now.

Hi Nofew,

There is a known problem which you seem to have that causes the D1 BSOD.
As i said previously you seem to be using multiple IP's that are failing to correctly bind and this in turn creates the Race condition referred to here, with a fix.

http://support.microsoft.com/kb/2905412

As for your IRST drivers i did mention there are 2 versions
RST and AHCI Driver and GUI

Download Intel® Rapid Storage Technology (Intel® RST)
(use the bottom set iata.enu)


The tool i asked you to run comes back clean, so no worries there.

As for drivers my mantra
OEM use thiers
Custom Build Manfacturer only

note is your firmware upto date on your expansion drive.



Roy



Roy

torchwood: Since backing previous Windows Updates up is more difficult (as far as I know; if there's a way, *please* tell me!), I just want to ask for clarification before throwing that update on; how sure are you that it applies to me? I imagine that if that was causing my problems, I'd get BSODs pointing to my networking drivers instead of my disk drivers. Additionally, the page you linked to says that it happens in a multiprocessor environment, and I only have one processor.

As for the drivers you liked, the first one worked! Sort of! See, the first one you linked is from 2012 and what I originally used to install the first driver in the first place; installing it again will just throw me back to square one. At the top of the page there is a link to a newer version, made in 2015, which goes to Download Intel® Rapid Storage Technology (Intel® RST) . SetupRST.exe is the one I tried that claims I don't have any compatible hardware.

The other driver you linked is even older than the first one, though it has no later version.

The drive's firmware is up to date. I'm sorry I forgot to mention that, that's probably very relevant. It was one of the first things I checked when first put the drive in this system.

Normally I'd ask what suggestion you have for me from here, but keep reading.


Everyone (especially axe0 and Layback Bear): I am no novice when it comes to disaster recovery. At the moment my system isn't in a "disaster" state (at least due to software, next paragraph'll explain) because it's just crashing more than I'd like it to, but no data is being lost and I can still try different things. Now, if I suddenly can't boot to Windows because some program installs an audio driver where there should be a disk driver or something, that would be a disaster state, I actually know how to handle this particular one and can fix it. If this does come back to haunt me two months from now, so be it, I'll deal with it, and I have the original drivers anyway. I wouldn't have followed MSClint's suggestions so quickly or willingly if I wasn't sure that I could revert them if the worst happened.

Anyway, kinda important!: Drive's failing. <.< It really was just really crazy timing. Now my BIOS doesn't even detect the drive sometimes when I try to boot and I have to keep changing its priority. This definitely isn't something a driver update would cause, considering it happens before booting and thus before any drivers are loaded. Reallocated sector count is up to 1,168. The drive appears to have fun out of sectors to reallocate; other metrics are reporting rather worrying numbers. A new drive is already on the way, and I have working backups. I'm going to try to figure out specifically which files are affected by the bad sectors that already exist, and I have some strong suspicions that we'll see the original IaStorA.sys and storport.sys files are damaged and the new driver update didn't technically fix a bug; it just utterly restored the existence of some data.

Paranoia finally hit and budget allows it, so we're goin' RAID-1 this time! Whoo!

Hi Nofew,

Its ALLWAYS good to sort out problems,
but with a faling drive it actually makes it near enough impossible to fix it.
You first have to identify whats in those sectors/blocks, I dont even know if theres a tool that can.
Chkdsk /r will try to correct them.

As Axe0 confirmed you do have multiple processors, and all the other pieces in the jigsaw seem to fit, i would install the hotfix.
(If this was an old rig i would have said not, but you've just rebuilt)
Theres a heirachy within the system. High and low level, if a low level driver has a dependancy on a higher level being active, it would not throw a BSOD just an event entry
device-xyz failed to start as a service upon which it depends has not started

Removing any update is an easy job, one click and your done

Regarding IRST
The tool i asked you to run, 50212, throws up specific errors in it telling me its a bad install, and its the only one i know that does, it also makes the OS non-genuine.
The standard fix is the IATA.ENU update. Even tho its dated 2012, the newer versions i believe are more for the W8, W10 and UEFI Bios set-ups.
(its also a known fact that some older drivers work better, go figure!!!)
NOTE
when applying this type of update peripherals should NOT be attached and BIOS set to default values.


Disaster recovery = Macrium


Roy

axe0: Thank you for taking the time to explain your position to me. It actually means a lot and really helped clear the air! I often forget how forums work and that other people who might not be as knowledgeable as me with regards to certain procedures might come along with the same problem I'm having, but not be able to interpret the solution if it isn't explained delicately.

torchwood: Once the new drives come in, if I'm still crashing, I'll follow your instructions with regards to the patch.


Everyone: Aight, casualty report!

No irreplaceable files are unrecoverable. The end! (You can stop reading here if you're busy. Keep going if you want to see all detective work.)

So, I booted up SystemRescueCD, a Linux distribution that has a bunch of tools baked into it to help in situations like these. First is ddrescue. I use it to copy a raw disk to a file on another disk. When first invoked it works sequentially, but if it encounters an Unrecoverable Read Error (I'll call that a "URE" from here on out) it skips ahead a megabyte to try and clear the problem area as fast as it can and read more data, in the event that the disk is actively breaking down and you want to rescue as much as possible. Whenever it hits a URE, it makes a note of it in a special "map file" that it stores next to the data file it's creating.

Once it's done reading what it can on the first go, it reads its map file and goes to the /end/ of the problem areas, then reads 512 bytes (or 4096, if your drive is one of those) backwards at a time until it finds the real end of the problem area. It puts this data where it's supposed to go in the copy it's making, and notes the real size of the problem areas in the map file.

Finally, one it's done doing that, it'll retry the bad sectors as much as the user allows it to, either until it gets data or the disk dies.

The big critical thing here, aside from how mind-blowingly useful this tool is, is that the map file it creates has a list of all the bad sectors and their sizes!

The contents of my map file are as follows:

Code:

# Mapfile. Created by GNU ddrescue version 1.21
# Command line: ddrescue -r3 /dev/sdc /mnt/rescuedrive/DDWolf/C_Drive.img /mnt/rescuedrive/DDWolf/C_Drive.map
# Start time:   2017-12-05 14:39:04
# Current time: 2017-12-05 14:58:56
# Retrying bad sectors... Retry 1 (forwards)
# current_pos  current_status
0x299A3E5EA00     -
#      pos        size  status
0x00000000  0x299A2BF4000  +
0x299A2BF4000  0x00005000  -
0x299A2BF9000  0x0121C000  +
0x299A3E15000  0x00009000  -
0x299A3E1E000  0x00004000  +
0x299A3E22000  0x00004000  -
0x299A3E26000  0x00001000  +
0x299A3E27000  0x00004000  -
0x299A3E2B000  0x00002000  +
0x299A3E2D000  0x00002000  -
0x299A3E2F000  0x00005000  +
0x299A3E34000  0x00002000  -
0x299A3E36000  0x00001000  +
0x299A3E37000  0x00004000  -
0x299A3E3B000  0x0000E000  +
0x299A3E49000  0x0001D000  -
0x299A3E66000  0x20FD610000  +

The lines consisting of two hex values and a + or - after them are the important ones here. The first value is a location on the disk, and the second is a size. The + means that data was read from that location and it's as big as the second column specifies, and - means that there's a bad sector there, as big as the second column specifies.

"Bad sector" in this context specifically means that ddrescue encountered an URE.

So, now we have a list of all the bad sectors, and how many sectors they go on for. None of the values in the second column are /massive/; it's not like any are reading out as gigabytes, though we do have some large ones around a megabyte in size. Obviously worrying; that could be entire files missing, but it's unlikely that my entire photo library is shot, for example.

Using the information in the map file, we can determine which specific files are affected. First we need to convert one of values on the left in a row that ends with a - to decimal. 0x299A2BF4000 in decimal is 2858883694592.

Okay, easy enough! Next, we take that value and divide it by our NTFS volume's "cluster size". That'll almost always be either 512 or 4096, and does not necessarily have to match up with the physical disk's sector sizes. System Rescue CD's "ntfsinfo" command can give us that. In my case it's 4096.

2858883694592 divided by 4096 is 697969652. This means "697969652" is the specific cluster in my NTFS volume where Windows decided to store the data in question that now happens to reside in a bad sector.

SRCD's "ntfscluster" command can take a given cluster and output the name of the file (and inode) that it's associated with. Bada-bing-bada-boom, we have our file!

Note: This does not magically show what data was in that sector; all it does is help you determine what you lost. It's helpful if you want to know if you lost part of a Steam game that you can just redownload or if you lost your TurboTax file and now need to recreate it from scratch before you get in trouble. While /technically/ if you deeply understand individual file structure you might be able to use the information we've gained so far to fill a picture with padding so a .jpg or .png still opens but has a hole missing or something, that is beyond the scope of what I know well enough to feel confident in explaining right here right now.

In my case, holy cow I got so blessed. o______o All of my sectors are in the same file, and it's a Steam game, and I can just redownload the data! WHOO!

HOWEVER! Hold your horses, we're not done here yet!

This is not the first time I have rescued this drive. The map file actually lists the exact same sectors and sizes as one of my previous runs! Okay, so, drive not failing, go cancel the shipment of those new drives, right? Weeeellllll...

While creating this copy, my drive kept making really weird noises and progress kept seizing up. Although it didn't hit any new UREs, it hung for *obscene* amounts of time while trying to read data. After listening closely, I believe that the arm on my hard drive is beginning to stick and having issues moving into the proper places. This is obviously unbelievably risky as it could write over incorrect data, and it explains why I was crashing at random; data doesn't come in when it's required, system needs it *now*, bang.

The longest reads that I measured to any reasonable degree of accuracy took around 25 seconds. The usual waiting period, even on a mechanical hard drive that's under heavy load, is probably closer to a few hundred milliseconds. That's going to mess with some things.

It also explains why I sporadically appeared to have no MBR; arm didn't move into place to actually /read/ the MBR, BIOS thought the disk just didn't have one after some timeout expired, and so the disk wasn't always listed in the boot menu.



For those looking for more information, or to accomplish these steps themselves, please read the following pages:

GNU ddrescue Manual Read this *thoroughly* when you get the chance, but if a drive is failing now-now-now, the bare minimum is "ddrescue /dev/failingdrive /mnt/gooddrive/data.rescue /mnt/gooddrive/map.rescue". IF YOU ARE NEW TO LINUX, DO NOT MESS WITH ANY OF THIS! IF YOU DON'T UNDERSTAND EXACTLY WHAT THAT COMMAND IS DOING AND HOW TO MAKE IT WORK ON YOUR PARTICULAR SYSTEM, YOU CAN MAKE THINGS INFINITELY WORSE! FOLLOWING ANY STEPS IS "AT YOUR OWN RISK".

http://www.radagast.ca/linux/how-to-...ing-linux.html These are the specific steps to find out which files are associated with which blocks after running ddrescue. It goes into more detail than I did and contains command line syntax, which I found especially helpful since nerves tend to make me mis-type otherwise simple things.

SystemRescueCd - System Rescue Cd Homepage System Rescue CD's homepage. Click "Download" on the left, along with "Bootable USB" if you don't have or can't use an optical drive.

I know this section of my post is fairly terse, but this is a BSOD forum, not a deep data recovery and forensic forum. This should be enough to get someone who's self-motivated going. All that said, if your drive is failing right now, do not try to figure out what to do based on my text here, but instead find another page that gives more direct help more quickly for emergency situations. The way I've written things here, it'll take an average person a few weeks to figure out how to do this with no further help. Someone good with computers might take a few days. Only someone with decent Linux experience is going to be able to follow this in a time short enough to actually have a chance at saving something. While it is a good idea to read up on how to do these things just in case the worst happens and you're caught with your pants down, again, this is not a step-by-step "do this and bam you're good" guide!



Anyway, right now I'm waiting on the new drives to come in. Gunna swap stuff out once they arrive since I'm afraid of data corruption at this point; computer ain't even gunna be turned on until that's complete. I'll let'cha guys know if there's more issues or not after I've made the swap, re-imaged my data, reverted the drivers, and so on, so we know for sure, just for sake of curiosity, if I just have a failing drive or if I have a failing drive /and/ driver issues. See'ya in a few weeks!