That's probably a bug in the game.
Even if the O.E.M gave you 2 different sticks it's very dangerous. As said you should only have one model of sticks, not two. It might cause big problems if you have 2 different models.
But oh well, i hope the problem is solved now.
Well, in the past week, I've only had two application crashes and one lockup in total - one of the Mozilla update assistants (not the updater, but what relaunches the program after the update gets applied) had a BEX, Garry's Mod had the mentioned access violation (which looks like a bug, looking at the backtrace and the binary), and the Steam client locked up (I still have yet to find the entire chain of events which leads to it, but it is an application error). No system crashes (in either kernelspace or userspace) at all; this is in spite of running a lot of Minecraft (no JVM crashes) and X Rebirth (no game or system crashes; only issues were related to bugs in X:R, and were solved by restarting the game).
As a side note, last night I thought I got a BSoD, WINDOWS_CARTHORSE (MSDN: Windows put the cart before the horse), but the system uptime confirms that was just a dream (nightmare?), and MSDN does not appear to have any documentation on that error. I was also unable to determine the leadup for that, since it didn't write a core dump...not like it matters, anyway. My current theory was that I had been expecting a BSoD to occur in IRL testing, yet one did not.
Marking as Solved, since the initial reproduction steps no longer appear to result in a crash. If I detect spray through BitCoin or something, that would be a new thread, since this one has pretty much run its course, and I wasn't BitCoin spray testing during the driver debugging stages.
The best advice I can give regarding this is that if the memory checks good (even through single stick testing, which I did at one point), but there are still problems which can't be traced, check the memory again. 99% < 100%; you can never be too sure.
Quote