TCPIP.SYS-related BSOD Crash, Please Help. :)

Hello. I'm new to the forums, although I've frequently browsed the threads here when I have technical issues or just want to read up on how something works.

Lately I've been experiencing semi-regular BSOD crashes on one of my computers. It's an extremely mediocre setup (Sempron 2400+, 512mb, etc) that I use solely for running some P2P clients, so I don't have to waste resources on my other computer or leave it on constantly. Anyway, back to the issue.

Maybe 4-5 times a day I've been getting a blue screen of death. It used to just reboot, until I changed the "automatically restart" option in the hopes of getting some more info to try to solve the issue. The blue screen mentions TCPIP.SYS and some memory addresses, but aside from that doesn't give much of a clue as to what's going on. I *think* the problem is related to BitComet, as it only seems to happen with that app is running, though I haven't extensively tested that theory (I'm going to tonight, I plan on leaving it on without BitComet running and see if it crashes).

At first, after Googling the "Your System has Recovered from a Serious Error" message that I initially was getting after an auto-reboot, I thought it might be bad RAM, so I ran MEMTEST and sure enough there were errors, so I replaced that right away. MEMTEST no longer finds errors in the RAM, but the problem persists, unchanged.

Then I got to thinking about what had changed recently that might be a factor, and thought that the problem might have begun when I switched from my motherboard's onboard Marvell LAN to the onboard NVidia LAN, so I switched back and disabled the NVidia LAN in the BIOS, but no luck there either - it just crashed again right before I came here and started writing this post.

I've created debug logs of my minidumps for two of the crashes - the most recent one after switching back to the Marvel LAN, and an earlier one with NVidia LAN. I'll attach both, if anyone thinks they can glean any useful information from them. One difference I noticed is that the latter debug log, the one for the crash that occurred with the Marvel LAN, has a few error messages about being unable to identify modules, while the earlier crash does not.

I know for sure that it's not malware or a virus, as I've had Kaspersky Internet Security Suite running real-time protection and I've done a full scan on the highest protection settings. I also should mention that I did a fresh format very recently, installed all Windows updates, etc. Oh and, the problem DID exist before the format, I was hoping it would get rid of it.

I haven't completely ruled out the NVidia LAN as the culprit, since even though it's disabled in the BIOS the drivers would still be installed, would they not? Right now that's my only lead, since the problem did seem to start when I switched to that onboard LAN. Aside from that there's nothing I can think of except a hardware failure of some sort, and I've already ruled out the RAM by replacing it with a brand new stick.

Sorry this post is so long, but I always prefer to err on the side of too much detail than not enough.

So, can anyone suggest anything, or gather any clues from the debug logs? I'd be eternally grateful for any help.

PS. Crash1.txt is the earlier crash, with the NVidia LAN, and Crash2.txt is the later crash with the Marvell LAN.

 

UPDATE:

I tested a slightly different theory last night than what I said initially - I ran BitComet all night, but by itself - the other times I've been running it and the crash has occurred it was running alongside eMule. Anyway, NO CRASH with BitComet alone. I'm going to run it like that for the rest of the day to be sure and then run eMule alone tonight to see if that crashes it. If it doesn't, then that means that the crash only happens when both apps are running together.

Does anyone have any theories, at this point?

 

Please do the basics, run check disk and system file checker.
Also is the internal cleanliness of the pc up to scratch? Check the seating of the processor.
You are going the right way in general in eliminating possible suspects, you just need to deal with a few more to narrow things down.

Oh and Welcome to Major Geeks

 

Thanks for the reply.

I have run Check Disk several times, along with doing a complete defrag (including boot-time defrag of the MFT, page file, etc) with Diskeeper. I've dusted the inside of the computer out, as well as dusting out the RAM slots when I replaced my RAM before, thinking that was the cause of the problem. I've replaced the IDE cables, thinking maybe it was a hard drive write issue, and I've done a complete (time consuming) Check Disk scan for bad sectors. I've also completely replaced the paging file. I'm running ASUS' PC Probe utility to monitor power levels, temperature, etc. and it's not popping up any errors.

 

Considering you application, it is possible you are caught by the Microsoft security update to tcip.sys which reduces its capacity.

http://blog.davidkaspar.com/archives/2005/04/windows-xp-sp2-and-event-id-4226.php

 

I did patch my TCPIP.SYS file already to increase the number of half-open connections for BitComet. Then while troubleshooting this crash I reverted back to the backed-up original TCPIP.SYS, thinking that patching it might have caused my problems, but no, it still happens with the original file.

Also, I've read that the number of half-open connections doesn't really cause a big problem for BitComet if you have a fast connection. In the system event viewer, there's a certain warning message that pops up when the system hits that half-open connection limit, and with the original, unpatched TCPIP.SYS file I only saw that warning message twice over a period of about 5 hours.

 

Your efforts on the hardware side does seem to point away from a hardware problem towards an overdriven software one.

Just skipping through your logs, the pc seems to have a lot of unnecessry stuff loaded. Could you cut back?

Have you tried it without the Kaspersky? Is that new?

 

Hmmm... I've onloaded Kaspersky now, simply because the last crash seemed to corrupt some if its files and an update didn't fix them. I wonder if that's the reason it hasn't crashed, rather than the lack of emule. I'll uninstall and reinstall Kaspersky to get it working properly again, and then I'll test with just it running and see if the crash still occurs.

 

Okay, I just came back to the computer to find that it HAS crashed again, with just BitComet running. It just took a LOT longer before it crashed, it seems. In my system tray, all that I had running was BitComet, NetLimiter, and PeerGuardian. So that rules out Kaspersky Internet Security Suite and eMule, but doesn't conclusively place the blame on BitComet yet. Tonight I still plan to run it without BitComet and see if it crashes still.

This is really frustrating, but I do sort of feel like I'm making progress, at least in ruling things out.

 

Here's the debug log and minidump for the latest crash, the one I just described in my previous post.