Random BSODs on a brand-new PC (ntoskrnl.exe)

Analysts:


Continued...

TBH, this is the item here that had me pretty stumped. Part of me thinks that a little bit of math was involved in calculating the previous size, since 0x3 and 0x4 add up to 0x7 which is the correct amount, it might have thought that there was another allocation sitting here. In fact, upon pondering on it further, there probably was!

See, what it looks like now, is that this wasn't because the pool allocation for the Config. Manager happened to have been originally 0x70 and all of a sudden was reduced to 0x30. Rather, the original value was probably in fact 0x30! So the Configuration Manager erroneously allocated 30 bytes for this region when it was supposed to be 70, and then it indeed overflowed by shoving that long string of text into it, which spilled over and completely obliterated the pool allocation made after it.

This is where the plot thickens. Now the problem is, we need to know where on earth the Config. Manager decided to allocate 30 bytes instead of 70 like its previous allocations. When dumping the raw stack of this faulting thread I do see that before the attempt to free the pool (which, btw, is the only time when Windows - without Driver Verifier - checks for pool corruption) allocation that has the erroneous size, that this thread did previously allocate some pool (e.g. nt!MiAllocatePagedPoolPages) so now I have to figure out if this is the same pool allocation we're dealing with, and if so when it gave the request to allocate 30 bytes instead of 70. This is where things get pretty heavy, and where I seriously doubt I'll be able to pull much from this minidump, but I'm willing to give it a shot.

That's all I have for this right now, but my suspicion still rests on hardware problems. The fact it's only a bit away from being correct is just too close to be a suspected driver bug, and TBH I'm not sure any third party driver was bugging here, since this looks like it was all on the Config. Manager (which, btw, is the subsystem in Windows that implements the registry, hence the registry keys in the pool allocations). It just looks too much like a hardware fluke right now, so I still recommend approaching it with that hypothesis in mind.

If a term or statement is going over your head that you can't seem to grasp, you know who to contact! Remember, this thing still ain't done, and I'm going to try and dive a bit more, though now it means stackwalking, which is a love-hate relationship for me.

First of all, thanks both of you for all the help provided.

There's too much information above, I'm just trying to understand those, but this is driving me crazy, I'm too much confused! lol

Vir Gnarus said:

Again, if it ain't RAM, then it's gotta be Mobo/CPU/PSU that's causing it. Can you provide an HWInfo sensor log (check Sensors only at startup) for about 30 minutes or until (if possible) a crash?

Started logging with HWInfo64. Should upload the .csv file created, right?
I'll just wait the next crash and upload it.

Vir Gnarus said:

Oh, and in your original post, the reason the Razer driver isn't letting Windows start when DV is on is because DV is seeing that the driver is performing something that'll corrupt the system. Razer drivers are notorious for their shoddy programming and bug-addled natures, but right now all you can do is try to find an update for them as well as any potential firmware update. Otherwise, I will have to recommend testing the system's stability with the driver uninstalled and resorting to the default Windows mouse driver.

After my last Windows install, Razer driver isn't crashing on DV startup, don't know why..

Vir Gnarus said:

Btw, I also noticed you said you just purchased this system like a month ago. Did you build it or is it a custom-built PC from a local PC shop?

I've built the system, hardwares are from diferent stores.. Only PSU, mobo and case are from the same shop.

And maybe that's the worst part of it. If it's hardware, as it sounds like, I just need to know which one is.
Need something to argue with the stores about the RMA.
For example, the RAM stick.
Both are doing well on memtest86+, but I'll try to RMA it anyway.
Store seller will have to make "several tests" for a possible exchange.
IMO, the store will only make the same tests I did, and it will pinpoint no errors at all.
And I'll return with the old sticks.

Could it be the GPU?
I was bought from an online store, it may be the most difficult hardware to RMA. Hope it's not the problem.
At the next crash, I'll remove it from the computer and check system stability without it.

Once again, thanks both Arc and Vir Gnarus for all the help you're giving me.

Most of the information is only directed towards fellow analysts. The stuff you responded too is for you to read.

Yes, you should upload the .csv file(s). If you can't somehow due to file restrictions, zip them up first and upload that.

The Razer drivers still should be kept updated and the firmware for your product updated as well whenever possible, or removed altogether. Also, make sure DV is actually on by opening it again and doing a "Display current settings". If driver list is empty and/or checks are all off, then DV is not on.

The problem with a lot of hardware issues, especially if it does end up being Mobo/PSU/CPU - which is most likely - then it can be extremely difficult or nearly impossible without swapping parts to figure cause. That's because they all are very intricately interconnected, and any problem with one will show up as issues with the others (except PSU, and prob with that will show up issues for anything else). That's why having an available diagnostic system to swap suspect parts in and test is kinda crucial in many cases. There are no diagnostic software tests for mobo or PSU, but the HWinfo may show signs of PSU problems.

If the shop is offering to do some of the tests, let them. Often they will isolate parts to find a problem part, and/or use stuff like a PSU tester to figure problems with that. They have resources you probably don't, so unless you wanna spend to get em, your best option is to let them take a gander at it. We will continue to work with you as much as we can, but there's only so far we can go without the proper equipment and environment.

Hey there, skipper, just want to make sure you're still with us. I'm interested in continuing work on this.

Hello, guys.
Sorry for the late reply, had to travel.

Ran the HWinfo last time, not for so long, couldn't get a crash.
Uploading the CSV though.
Will be running this again later.

I might try RMA the RAM this thursday, taking several days for the reply.
Thinking of buying another 4gb stick to have the machine working, but just don't have the money right now, don't know if it would be worth the value, as they can't work together later.

The intent is to run HwInfo while doing something that you believe will invoke a crash. HwInfo only logs thermal and voltage information, but you'll need to stress the system with something else (like Prime95 or some benchmark or game).

I'll continue to work on the latest crashdump you've provided seeing as I am heading in a good direction with it. Have you been suffering any more crashes with the system since then?

None new crashes yet.

I just don't know what can cause the system crash.
It can BSOD multiple times on idle and none while gaming, for example.

I'll try stressing it right now with Prime95 while HWinfo is on.