Windows 7 BSOD After Installing New RAM

[CPT Gray Wolf]

I just tried to upgrade my old computer from 4gb (4x1gb) to 6gb (2x1gb 2x2gb), but windows wouldn't boot up. It would start to boot, then immediately BSOD. It gave me 3 different BSOD's, first IRQL_NOT_LESS_OR_EQUAL, then PAGE_FAULT_IN_NONPAGED_AREA, and then BAD_POOL_HEADER. WTF!!!

I've determined it's a problem with Windows (7 x64 Ultimate), but I don't know what it is.
If couldn't even go into repair or safe mode.

If someone could help I would appreciate it.

 

[tachybana]

Try removing the Memory and see if that allows it to boot. If it does then you have faulty memory. Please give me the specs on your mother board as well

Thanks

 

[CPT Gray Wolf]

Try removing the Memory and see if that allows it to boot. If it does then you have faulty memory. Please give me the specs on your mother board as well

Thanks

The thing is, I put the RAM in another computer running Linux, and it had no problem. It's just Windows.

 

[johnbl]

-most likely incorrect memory timings set in the BIOS. (check for correct voltage to the memory in BIOS)
- also, make sure you pair the modules in the correct banks. Matched banks are normally not next to each other on the mother board.

-BIOS update will fix a lot of the autodetection of memory settings or you can confirm that the voltage and memory settings are correct for your new memory.

After you get the system working you will want to run memtest86 booted from a CD or USB to confirm your hardware memory timings work as expected.

 

[CPT Gray Wolf]

-most likely incorrect memory timings set in the BIOS. (check for correct voltage to the memory in BIOS)
- also, make sure you pair the modules in the correct banks. Matched banks are normally not next to each other on the mother board.

-BIOS update will fix a lot of the autodetection of memory settings or you can confirm that the voltage and memory settings are correct for your new memory.

After you get the system working you will want to run memtest86 booted from a CD or USB to confirm your hardware memory timings work as expected.

There's nothing wrong with the RAM itself, or the BIOS. I've tested all the hardware aspects, that leaves the OS.

 

[johnbl]

The hardware can be fine, the software in the BIOS sets up the hardware configuration and it is what is most likely the issue. The errors you indicated would be cause by memory corruption. The most common cause of memory corruption is incorrect settings in BIOS for the memory timings and voltages.

Then third party device drivers corrupting shared memory structures in the kernel of the OS.

by running memtest86 you boot onto a non windows OS and eliminate windows from the problem and can focus on getting your BIOS settings correct or finding a defective part.

if memtest86 works, you swap the modules and try again. if it continues to work and windows fails
you look at the crash dump with a debugger. In your case I would look at your hardware settings in the crash dump to get a clue as to the problem, then at the various drivers you have installed.

-most likely incorrect memory timings set in the BIOS. (check for correct voltage to the memory in BIOS)
- also, make sure you pair the modules in the correct banks. Matched banks are normally not next to each other on the mother board.

-BIOS update will fix a lot of the autodetection of memory settings or you can confirm that the voltage and memory settings are correct for your new memory.

After you get the system working you will want to run memtest86 booted from a CD or USB to confirm your hardware memory timings work as expected.

There's nothing wrong with the RAM itself, or the BIOS. I've tested all the hardware aspects, that leaves the OS.

 

[CPT Gray Wolf]

The hardware can be fine, the software in the BIOS sets up the hardware configuration and it is what is most likely the issue. The errors you indicated would be cause by memory corruption. The most common cause of memory corruption is incorrect settings in BIOS for the memory timings and voltages.

Then third party device drivers corrupting shared memory structures in the kernel of the OS.

by running memtest86 you boot onto a non windows OS and eliminate windows from the problem and can focus on getting your BIOS settings correct or finding a defective part.

if memtest86 works, you swap the modules and try again. if it continues to work and windows fails
you look at the crash dump with a debugger. In your case I would look at your hardware settings in the crash dump to get a clue as to the problem, then at the various drivers you have installed.

The BIOS setting are fine, not to mention that all the sticks of RAM share the same settings, and the 2x1gb sticks are currently running fine. Memtest shows no problems, and the system itself boots up fine. It's just that Windows won't start.

 

[johnbl]

cool, does windows write a crash dump? if so post it on a cloud share like skydrive with public access and I can take a quick look

The hardware can be fine, the software in the BIOS sets up the hardware configuration and it is what is most likely the issue. The errors you indicated would be cause by memory corruption. The most common cause of memory corruption is incorrect settings in BIOS for the memory timings and voltages.

Then third party device drivers corrupting shared memory structures in the kernel of the OS.

by running memtest86 you boot onto a non windows OS and eliminate windows from the problem and can focus on getting your BIOS settings correct or finding a defective part.

if memtest86 works, you swap the modules and try again. if it continues to work and windows fails
you look at the crash dump with a debugger. In your case I would look at your hardware settings in the crash dump to get a clue as to the problem, then at the various drivers you have installed.

The BIOS setting are fine, not to mention that all the sticks of RAM share the same settings, and the 2x1gb sticks are currently running fine. Memtest shows no problems, and the system itself boots up fine. It's just that Windows won't start.

 

[CPT Gray Wolf]

cool, does windows write a crash dump? if so post it on a cloud share like skydrive with public access and I can take a quick look

No, it still has the crash dump from some BSOD I had months ago. It didn't save any of the new ones.

 

[johnbl]

cool, if you have your system to save the crash dump and it does not save it. I would suspect that the OS lost access to your drive. on a mostly working system this can happen if a drive does not respond in a certain timeout value (30 seconds). Pretty common issue with certain firmware conditions on solid state drives. The device takes too long to respond, windows resets the SATA port and forces a disconnect but the drive never reconnects and later a critical process needs access to the drive and bugcheck is called. no drive access= no memory dump file and the error logs will also not have been created. (I have seen a system with plenty of memory go for 4 hours before a critical process called a bug check)

Work around for this would be to make sure that hotswapping is enabled for the SATA port that the drive is connected to. this way if windows resets your sata port it will auto reconnect and there will be a event log to show for it. (later you have to figure out why the drive did not respond in time, bad cables connections (thermal issues with cable) , need updated chipset drivers, firmware issues in SSD, these type of things )

after you get your system to bugcheck and make a memory dump. let me know and I will look at it.

 

[CPT Gray Wolf]

cool, if you have your system to save the crash dump and it does not save it. I would suspect that the OS lost access to your drive. on a mostly working system this can happen if a drive does not respond in a certain timeout value (30 seconds). Pretty common issue with certain firmware conditions on solid state drives. The device takes too long to respond, windows resets the SATA port and forces a disconnect but the drive never reconnects and later a critical process needs access to the drive and bugcheck is called. no drive access= no memory dump file and the error logs will also not have been created. (I have seen a system with plenty of memory go for 4 hours before a critical process called a bug check)

Work around for this would be to make sure that hotswapping is enabled for the SATA port that the drive is connected to. this way if windows resets your sata port it will auto reconnect and there will be a event log to show for it. (later you have to figure out why the drive did not respond in time, bad cables connections (thermal issues with cable) , need updated chipset drivers, firmware issues in SSD, these type of things )

after you get your system to bugcheck and make a memory dump. let me know and I will look at it.

Two problems:
1. My motherboard doesn't support hotswapping.
2. I'm not using an SSD.

My system is kind of outdated and a lot of BIOS setting are off limits, because Dell.

If I had the money I would build a new computer, but I have like $4.16 to my name, and at the moment I'm not making any money.

 

[johnbl]

no problem, that leaves you with putting your drive on another SATA port, and disconnect the cables and reconnect them to make sure they are seated correctly.
after you boot you will want to get the chipset update for your CPU. if it is a intel board you can get the drivers directly from the intel website (google "intel chipset drivers"). Also, if dell knows of a motherboard design flaw, they will update the drivers to workaround the problem and put them on their website for their motherboard.
also, just go to dell and grab the latest BIOS for your machine. They will make fixes and never bother to tell people.

cool, if you have your system to save the crash dump and it does not save it. I would suspect that the OS lost access to your drive. on a mostly working system this can happen if a drive does not respond in a certain timeout value (30 seconds). Pretty common issue with certain firmware conditions on solid state drives. The device takes too long to respond, windows resets the SATA port and forces a disconnect but the drive never reconnects and later a critical process needs access to the drive and bugcheck is called. no drive access= no memory dump file and the error logs will also not have been created. (I have seen a system with plenty of memory go for 4 hours before a critical process called a bug check)

Work around for this would be to make sure that hotswapping is enabled for the SATA port that the drive is connected to. this way if windows resets your sata port it will auto reconnect and there will be a event log to show for it. (later you have to figure out why the drive did not respond in time, bad cables connections (thermal issues with cable) , need updated chipset drivers, firmware issues in SSD, these type of things )

after you get your system to bugcheck and make a memory dump. let me know and I will look at it.

Two problems:
1. My motherboard doesn't support hotswapping.
2. I'm not using an SSD.

My system is kind of outdated and a lot of BIOS setting are off limits, because Dell.

If I had the money I would build a new computer, but I have like $4.16 to my name, and at the moment I'm not making any money.

 

[CPT Gray Wolf]

no problem, that leaves you with putting your drive on another SATA port, and disconnect the cables and reconnect them to make sure they are seated correctly.
after you boot you will want to get the chipset update for your CPU. if it is a intel board you can get the drivers directly from the intel website (google "intel chipset drivers"). Also, if dell knows of a motherboard design flaw, they will update the drivers to workaround the problem and put them on their website for their motherboard.
also, just go to dell and grab the latest BIOS for your machine. They will make fixes and never bother to tell people.

Well everything is as up to date is it can get. My system isn't supported anymore, they haven't had a BIOS update for it in a couple years.

 

[johnbl]

old BIOS are not too smart when I comes to adding new memory. It can detect the faster memory and set the slower memory bank to the same speed as the faster memory banks. extra memory on some older systems require that you underclock the memory when you add the extra banks.
your left with booting on a memtest86 cd and confirming that your memory subsystem hardware works as expected. then run a hard drive test to confirm that it runs as expected. Both of these can be run without involving windows.
give it a shot. if you ever get the memory dump let me know and I will try to take a look.

 

[CPT Gray Wolf]

old BIOS are not too smart when I comes to adding new memory. It can detect the faster memory and set the slower memory bank to the same speed as the faster memory banks. extra memory on some older systems require that you underclock the memory when you add the extra banks.
your left with booting on a memtest86 cd and confirming that your memory subsystem hardware works as expected. then run a hard drive test to confirm that it runs as expected. Both of these can be run without involving windows.
give it a shot. if you ever get the memory dump let me know and I will try to take a look.

Like I said, it's not the BIOS though.

 

[johnbl]

The BIOS is dynamically configured, change its hardware setting and change it back to force it to rebuild its internal database that it sends to the OS. Or reset it to defaults and reconfigure. I guess dell would just ask you to tell them what memory module you have and compare it to its old list of qualified memory.

time to punt:
Maybe someone else can figure out your machines issue.
good luck.