BSoD 0x3B - system doesn't create dump files

But it is more convenient for me to update the system than to enter the BIOS and overdo it there just to update it. I just have a program on my system that simplifies the BIOS update process
 
MrPepka said:
You mentioned occasional failures, for me every start of the AORUS Engine program ends with BSoD where as I mentioned earlier the program worked great
Click to expand...

I apologise, I misunderstood what you said in your previous post, however, it's even worse if as soon as you load the said program it results in a BSOD. I would strongly suggest that you remove anything associated to the Gigabyte tools.
 
OK, but I want to use these applications, especially the APP Center because, as I mentioned, there is a BIOS update program that I use. In turn, AORUS Engine is a program to control the work of the graphics card and removing it is actually just masking the problem than its solution. Well, unless my conclusions about Logitech drivers are wrong, but on the other hand this is the only clue I have (as I mentioned earlier, and APP Center and AORUS Engine running together did not cause any problems and that's why I think that the fault is not on their side)
 
Of course they are, but I won't be sure that they will work if the one I have doesn't work. At least I want to make sure that my method of analysis using irpfind is correct and whether I am accidentally erring (because of course I assume that I can draw wrong conclusions, but I want to be sure because maybe with this bugcheck irpfind is still applicable and can be effective)
 
MrPepka said:
(as I mentioned earlier, and APP Center and AORUS Engine running together did not cause any problems and that's why I think that the fault is not on their side)
Click to expand...

You mentioned in your previous post, that attempting to boot the AORUS Engine program always results in a BSOD?
 
MrPepka said:
Of course they are, but I won't be sure that they will work if the one I have doesn't work. At least I want to make sure that my method of analysis using irpfind is correct and whether I am accidentally erring (because of course I assume that I can draw wrong conclusions, but I want to be sure because maybe with this bugcheck irpfind is still applicable and can be effective)
Click to expand...

Please read through my analysis of the crash dump to understand why using !irpfind will not be of any benefit. Please take note the bugcheck parameters too.
 
OK, I have read it and it shows that the Gigabyte driver is undeniably guilty. OK, but what can I do? How about running APP Center and AORUS Engine as an administrator? Well, because the driver tried to execute the instruction without authority, so maybe if he had the appropriate authority, BSoD would not be there?
However, a false trail because it did nothing :mad:
 
Last edited:
OK, I think I understood better now why irpfind is a bad idea. Now in the list I have Corsair drivers that I didn't have before. So in short, this command simply shows the loaded drivers themselves when a failure occurs, and they may not necessarily be responsible for it. So I have to face the truth and accept that the Gigabyte driver is guilty? It is a bit strange that suddenly it started to cause blue screens now, and before it worked without a problem, but oh well
I tried to start Driver Verifier, but after restarting the computer did not start, but the symptoms were strange. Even very strange. The computer at startup displayed only a black screen, but even the BIOS screen did not show, only black (the monitor received a signal from HDMI because it displayed the appropriate message). The third time the system started automatic repair and in safe mode I could turn off Driver Verifier. When I did that, I could start my computer normally. I have never encountered such a thing in my life
 
Last edited:
Okay, I gave up and replaced AORUS Engine with MSI Afterburner. Perhaps something else was to blame, but I don't feel like it anymore. You can close the topic
 
MrPepka said:
OK, I think I understood better now why irpfind is a bad idea. Now in the list I have Corsair drivers that I didn't have before. So in short, this command simply shows the loaded drivers themselves when a failure occurs, and they may not necessarily be responsible for it.
Click to expand...

No, !irpfind lists all the currently active IRPs and I/O stack locations. It doesn't show drivers which have failed.

MrPepka said:
OK, but what can I do? How about running APP Center and AORUS Engine as an administrator? Well, because the driver tried to execute the instruction without authority, so maybe if he had the appropriate authority, BSoD would not be there?
Click to expand...

No that wouldn't work, the NTSTATUS code isn't referring to if the program has administrative access. It's referring to the processor privilege level, which is commonly Ring 3 and Ring 0. From the Intel documentation for the rdmsr instruction:

This instruction must be executed at privilege level 0 or in real-address mode; otherwise, a general protection
exception #GP(0) will be generated. Specifying a reserved or unimplemented MSR address in ECX will also cause a
general protection exception.
Click to expand...

I would strongly recommend reading the following article - CPU Rings, Privilege, and Protection
 
OK. Does this document apply to AMD processors?
Oh, and such a question. When does irpfind apply? For example, does the IRQL level error code apply? I ask because from time to time WinDbg shows the IRP address when debugging the blue screen with error code 0xA (in 0xD1 and 0x50 I have not encountered it yet)
 
Last edited:
MrPepka said:
Oh, and such a question. When does irpfind apply? For example, does the IRQL level error code apply? I ask because from time to time WinDbg shows the IRP address when debugging the blue screen with error code 0xA (in 0xD1 and 0x50 I have not encountered it yet)
Click to expand...

I've never really found a reason to use !irpfind, however, it would be useful for situations where you wanted to see which IRP stacks a driver may be part of.

You don't need to worry about IRPs with Stop 0xA, Stop 0xD1 and Stop 0x50. With those bugchecks, you'll what to check which instruction caused the error and investigate why that memory address is invalid. Typically, the driver may be referencing an invalid pointer or referenced an address which resides in paged pool. Paged pool can't be accessed at IRQL Level 2 or above.
 
IRPFind is useful in situations where the current thread's IRP is completed, but not cleared, and there's no obvious thread link between two threads with pending or completed IRPs. I've seen drivers do this where they handle synchronization internally and spawn unrelated threads that complete IRPs making them hard to debug when they hang or deadlock. It's, in general, not useful... until it is :).
 
Hi,

For curiosity can I ask how did the problem "system doesn't create dump files" got resolved?
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top