That still doesn't mean it's not your PC. I've had plenty of bizarre problems with various programs over the years from faulty hardware, ranging from poor regulation on one of the power supply rails to bad RAM to a faulty motherboard.
It's also particularly tough with games, because in order to get desired graphic performance you're basically bypassing the operating system and mapping the graphic card into the process' address space - it's possible (and fairly common) to have an interaction in which the game pushes something to the graphics card, the card's driver returns something that's mis-aligned or has a pointer that's wrong (either because of a buggy driver or a buggy card) and the user-mode process takes a crash because of problems in the data. Sometimes it can be a problem in the user-mode process, as well - put things into the graphic rendering pipeline wrong and the user-mode process' memory may get corrupted or locked. That sort of bug is generally a showstopper that gets fixed pretty quickly. Bugs where there are subtle interactions between the graphics card and process are insanely hard to debug for the application developers because they'd need exact revs of cards and exact revs of drivers and they'd have to reproduce the entire interaction that caused the crash. In order to get the kind of framerates we gamers insist on, basically every graphical game is a "badly behaved process" that bypasses the kernel's protections in order to get speed. The designers of APIs like OpenGL and DirectX do what they can to firewall the process from kernel memory and card memory, and to prevent things from stomping on eachother by dint of design in the communications APIs but basically the driver and the user-mode application have control of the bus between them and they can screw up anything they want to between the two of them.
In other words, it's not uncommon at all for a bug in the top half of a card driver, or the bottom half, to manifest as a bug in the user-mode code. It could also be an unhandled exception (though those tend to get sorted out pretty quickly) for example a card driver that used to return one set of possible options suddenly starts getting it wrong and tanks the application because the application was expecting a return code between -1 and -25 and suddenly got -26...
Non-game apps don't have this kind of problem because they tend to rely on operating system level APIs where the O/S is careful about marshalling data in and out between kernel and application memory, and is able to error-check for compliance with standard requests. That's what an operating system does: provides common reliable services for user-mode processes. When a game program pushes straight past the kernel (which it has to do; windows' kernel task-switching is not efficient enough for 60fps graphics) it's accepting that there will be bugs.
When I first installed World of Warcraft on my game box, it crashed a few times. I noticed that when it crashed there was a particular clipping happening on certain textures, so I upgraded the graphic card driver and it never crashed again. Unfortunately, "that's gaming on a PC" and it's why consoles are generally pretty stable: standard hardware, lockstep driver configurations - they don't have to worry about weird interactions between a card some guy jiggered the GPU timing on and a card driver that the user hasn't updated since they bought it 3 years ago...
(Sorry that was a bit long-winded. I'm exploring and just got chatty between jumps)
Last edited: