Solved BSOD 0x0000000a on laptop when using wireless networking

[Ascaris]

Hi,

I am rewriting this post... I made a few mistakes in the previous version, which are now corrected. I've learned more about the issue at hand, and I will try to make it more concise.

I am getting persistent 0x0000000a bugchecks on my laptop (Win 7 x64 on F8Sp) when I try to write large amounts of data to a network share using the wireless card. It can happen any time from the first minute to a half hour or more in (with shorter times being far more common). It has never made it past an hour.

I tried several different drivers, including the one supplied with Windows and the one from Asus (among others), but that did not help. Neither did booting into safe mode with networking. However, when I booted into Linux (x64) from a Live DVD, it copied to the network share for three hours without issue before the laptop battery ran out as I slept, as I had somehow partly unplugged the power cord. I consider that a success, given that it usually crashed within a few minutes, and never went longer than an hour before.

I put Windows 7 x86 on a spare laptop HDD and tried that. It's straight Win 7 SP1, with no updates yet... I have installed the necessary drivers and nothing else. The wireless driver is the one included with Windows. As with Linux, It copied to the network share flawlessly; I let it chug along for three hours before I decided that was a success.

After that, it occurred to me... what if it is the 4GB limit that made it work in x86? I removed one SoDIMM, bringing the memory total to 4gb, and put the regular hard drive with Windows 7 x64 on it back in.

Again, it passed. But why would x64 Windows have problems with memory above 4GB? Linux x64 had no problem with it. It should not be a RAM issue; the system passed 7 hours of Memtest86+, and I have not had a single BSOD on this laptop with 7 x64 that was not related to this. Swapping the memory modules has had no effect.

I've checked for malware with my usual (Outpost Security Suite Pro), Kaspersky TDSS killer (I don't suspect anything, but it was handy), and Malwarebytes free. All report no malware (and removing one memory stick should not help if it was malware).

System specs:
Asus F8Sp-X1
Windows 7 x64
8gb DDR2-667
Core 2 Duo T7800 2.6 ghz
Intel PM965 chipset
WD Black 750GB HDD
HD 3650 GPU

I have attached the crash dumps as specified in the sticky. Any help is welcome!

 

[axe0]

Please post the report of Windows Genuine and Activation Issue Posting Instruction

 

[Ascaris]

I think I have it fixed.

After realizing that it did not crash with one of the two 4GB memory sticks removed, I began to fear it was a BIOS issue-- something that cannot be easily fixed, as Asus never released any firmware for the F8Sp other than the original, and the purported maximum ram of the device was 4GB (even though lots of people on the internet have successfully upgraded it to 8gb and reported no issues, which I checked thoroughly before I bought the two 4gb modules).

I may not be able to update the whole BIOS, but I can at least do something with the microcode. That made me think to look at my Windows updates to see which one of them contained microcode updates... I know I saw it in there somewhere, as I read the MS information for every update that is not a security update to decide if I want it or not (one more reason I don't like 10 in its current form).

I found the July 2015 microcode update in there. Upon reading the notes for that update, I noticed it said that if you install any language packs, you would need to install the update again. I haven't, but that suggested that this is a one-shot kind of thing (I admit to having no idea how OS-based microcode patches work, other than that they are loaded at boot time, unlike ones in firmware) in a way that other updates are not. I had just upgraded the cpu on this laptop... was one that had the same CPUID and family, and thus the same microcode, but maybe I am missing something about how that works.

I uninstalled the microcode update, rebooted, and tested the wireless connection again by copying a large (90GB backup file) to the network share. I let it keep going for the day, and it successfully copied the whole thing. It took somewhere between three to four hours. I was able to complete a backup to the network share for the first time too.

 

[Ascaris]

Ok, well... I was wrong about the microcode thing being the cause. Even though it was working, it didn't seem correct that this was the cause. I had the backup that had just completed for the first time to the network share, so I decided to keep digging. It was not long before I found the real cause.

I'd tried many drivers from different trusted sources (mainly laptop OEMs; who knows what you might get from some unknown driver web site), and when I went back to the MS-supplied driver, it BSOD'd again. The winning driver turned out to be the latest offered by Intel directly for my wireless card, which I am sure I tried before, but (shrug). It's still "solved," but I thought I should post this last bit of info for the benefit of others who may be reading this to solve similar problems.