Originally posted by: jonmcc33
< sigh >
When I got that there weren't any extensions added to Firefox. I know well enough that the more crap you add to Firefox the more unstable it becomes. I don't get some of you that are treating me as if I am some average user with no experience. It's really distasteful.
Now I expect the "It's not Vista, it's Firefox" comments. Wow, I have never gotten a BSOD while running Firefox in Windows XP. So obviously it's something to do with Vista.
I swear, I am going to do a new project and wipe my computer clean and install Vista. Then I'm going to make a new post here each and every time I have a problem with it. I guess I'll just get comments that it's my hardware or the software I am running. The irony will be that everything I do will be the same as if I am running Windows XP and I have no problems with my computer now. :roll:
I'll agree with you that it's not firefox. Happy? That's a user mode app and you're talking about a bugcheck (which can only occur because of a kernel mode problem). I'm not going to say you're an average user either...just an average admin perhaps.
From the bugcheck code reference in the WinDBG helpfile:
---------------------
Cause
Bug check 0x50 usually occurs after the installation of faulty hardware or in the event of failure of installed hardware (usually related to defective RAM, be it main memory, L2 RAM cache, or video RAM).
---------------------
Basically some driver tried to hit bad memory address (ended up having to page to go fetch it when it's in a non-pageable address.). Usually this isn't caused by a driver so downright retarded that it actually tried to do this instead this is VERY frequently caused by a bitflip...in other words damaged memory or a CPU caused a single bit to get altered and turned a valid address into something garbage.
Lets take a look at your case. The Stop 50 you got had a first parameter of 92CC4A90 and a 3rd parameter of 81CE892E.
The 81CE892E is the instruction where the reference was made from. It's a normal kernel-range address (Above 7FFFFFFF). The 92CC4A90 is suspicious though. It's a bit odd to see some code making a jump so far. Most assembly instructions are referencing data nearby...often within the same page. Longs jumps are uncommon. What abouts we break that number down into binary??
10010010110011000100101010010000 = 81CE892E.
What if that 2nd "1" was really a 0 and got flipped? (the first one getting flipped would take us into user mode address space...the kernel doesn't do this)
10000010110011000100101010010000 = 82CC4A90
82CC4A90 is much closer to the calling instruction.
I'm not saying this is what happened. You would need the full memory dump to be sure. Based off what typically happens in a Stop 50 though (bad driver or hardware) and the fact that folks all up and down this page aren't seeing what you are, I'd agree it's unlikely this is a problem with Vista.
You can continue on your bitching spree swearing up and down it's some code defect without any proof...or you could STFU and go find root cause. Note: wiping your computer does not find root cause..at best you would mask the issue or cause it to manifest itself as some other failure.