Getting a BSOD and wonder RAM sticks might be the cause? Is a memory test guarantee 100% assurance?

Solution 1:

No, the fact that the Windows memory diagostic tool passes does not mean your RAM is definitely fine. A much more thorough tool is memtest86. This tool often finds memory problems that do not show up in other tests. You'll want to run an extended test at least overnight.

Solution 2:

Windows memory diagnostic tool showed no errors. Can I conclude that the RAM sticks are fine? Or are there any other errors that are not recognized by this tool?

No you can't, I don't know of any software tests for RAM that are 100% infallible.

If the BSOD is a one off I'd put it down to a power issue, if it occurs more often I'd start looking at hardware and drivers.

Your error message could be related to drivers, check if you have updated any of your drivers recently. With errors like this the Microsoft site has a lot of troubleshooting information on specific errors. I won't go into them because your question is just about RAM, but I suggest you check out MS.

Solution 3:

This error indicates that some driver at the kernel level attempted to write to paged virtual memory (that means slow virtual memory that is baked by a hard disk's paged file) during interrupt request that was meant to be processed really fast. This is most likely a software fault.

Windows has several interrupt request levels (more info here and here). Some IRQLa are designed to handle system critical stuff like power mode changes, CPU clock ticks etc. The higher the level - the less stuff a driver can do. For example during a power failure a driver cannot access any memory - it's too slow for that.

If you want to troubleshoot this and pin-point a faulty driver you'll need to open memory dump that was collected right after the crash. You can double check the location of the dump in System Properties > Advanced > Startup and Recovery > Settings > Dump file. See the picture

You can then open dump file with tools, such as WinDbg (download the right version for your Windows) and in WinDbg you can run analyze -v on the dump. This should tell you which driver is likely to be at fault.