How to identify a driver conflict. How to fix DRIVER_VERIFIER_DETECTED_VIOLATION blue screen errors (0x000000C4). Troubleshooting errors that occur when checking drivers

A faulty driver can cause many problems for a computer. The most common sign that drivers need to be updated is the blue screen of death. Fortunately, this blue screen shows us error codes, memory dumps, which allows us to identify the cause in a particular driver, device and update or delete it. It becomes difficult when memory dumps and error codes do not help, or the computer does not even show error codes, but simply blocks the system. What to do in these cases?

Embedded in Windows Driver Verifier designed to test drivers by causing extra stress on system drivers and stress tests to cause a crash. This will help you identify bad drivers in Windows.

Preparing the system for windows 10 driver check

Before switching on Driver Verifier, note that drivers can lock you out of your own computer if you're not careful. Driver Verifier will give you a blue screen when it detects a bad driver, if there are several of them, then a download> download> crash cycle is formed and you will not be able to start back to the windows system to disable the crash test of system drivers. Therefore, we will prepare for every fireman, otherwise in our time the Russian "maybe a ride" is already weakly working. Do one of the following before enabling Driver Verification.

  • Check that you can easily boot into Safe Mode without the need for BIOS. In common words, entering Safe Mode must be done using the windows desktop. Hold Shift + Reload, while pressing and holding the Shift button, click on Reload with the mouse. Try another way, install the option through Windows.
  • Create a system restore point while disabling your antivirus products. Open Windows search and type Create a restore point, choose from the proposed and follow the instructions offered to you.
  • Create for your computer so that you can access the command line through options when using the recovery disk.
  • You can or any other data you are concerned about.
  • Be sure to read my crash test at the end of the article. He will help you in case of failure that happened to me.

Activating the windows Driver Verifier feature

Before activating the drivers, make sure you read the section above on how to protect yourself from endless loading.

  • Press Windows+R and type cmd to bring up the command prompt.

Enter the following code on the command line:

  • verifier

Specify item (for program code).

Select all but "DDI Compliance Check" and "Emulate Random Resource Shortage".

Click on the vendor column to sort. It is not necessary to select all drivers, only from other suppliers where there is no Microsoft Corporation inscription. If you are sure that the error is in any driver, then select all the items with checkmarks.


After all the settings, click Done and you will be told that the check will be performed after the system reboots. If the checker gives a blue screen, then write down the error code, memory dump and restart the computer.

Back in windows, you can disable driver checking in one of the following ways:

  • Go back, as you went through the command line and select the item delete existing options.

Open a command prompt and enter the following code:

How to Fix Cyclic Boot with Blue Screen of Death

  1. I want to note that I had a cyclic boot with a faulty driver. No error or memory dump code was provided, which is surprising to me.
  2. After 2-4 blue screen boot cycles, the System Restore option was automatically launched. In which I clicked "troubleshoot" > "advanced options" > "boot options" > "restart". Once downloaded, select 4 or 5 to boot in safe mode. Disable Driver Verification Manager as above.
  3. In order not to boot into safe mode, go to the option "troubleshooting" > "advanced options" and "COMMAND LINE". In which just type the command verifier /bootmode resetonbootfail.
  4. Copy or take a picture on your mobile phone, before starting to check the drivers, all 3 of the above points. Don't forget to copy the link to the article just in case.

How to open DMP file to view error analysis

  • The test files are on the path C:\Windows\Minidump.
  • You can open the DMP file format with

For such cases, to check how correctly the drivers work in Windows XP, there is a special utility verifier.exe. Utility driver Verifier, creates the most severe conditions for drivers, in which the probability of failure is very high, and the name of the failed driver is determined with the highest accuracy. Therefore, in case of non-systematic failures, it is useful to run the utility driver verifier.exe. There is no need to download Verifier, since the utility is included with Windows and is located in the directory Windows\system32


1 Working with verifier.exe

1.1. Let's run verifier.exe.Start - Run - Verifier.exe:

1.3. Utility driver verifier.exe will ask for a reboot:



1.4. Two new parameters will appear in the registry:


-- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDriverLevel

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDrivers
Registry settings related to driver verifier.exe

2 Test results

2.1. If in the first window of the utility driver verifier.exe select "Display information about currently tested drivers", then a window like this will appear. It shows which drivers are checked and which are not. pressing "Further", you can see other information about the tested drivers:

2.2. As a result of checking the drivers with the utility driver verifier.exe it is possible for the system to crash in . When an error occurs while checking drivers, system errors are caused and. Typical codes and error codes are shown below.

0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION
0xC6: DRIVER_CAUGHT_MODIFYING_FREED_POOL
0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION
0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION
0xE6: DRIVER_VERIFIER_DMA_VIOLATION


2.3. Examples of dump decryption by the program :


3. Useful links

Using the Driver Verifier Manager system utility supplied with Windows Vista/7, you can conduct a comprehensive diagnosis of the drivers installed in the system and find problematic components that disrupt the stable operation of the computer and equipment connected to it.

To run the mentioned tool, you need to register in Windows with administrator rights, then in the address bar of the Start -> Run menu, enter the verifier.exe command and click OK. As a result, a driver check manager window will open, in which you will need to scratch your head and decide on the appropriate option to launch the utility. You can perform both selective and full testing of all drivers without exception.

After setting the program operation mode and pressing the “Finish” button, you will need to restart the computer and wait for the operating system to load. If a faulty driver is detected, Windows will fall into the so-called “blue screen of death” (BSOD - Blue Screen Of Death) and report a critical error containing information about the problematic component, which must be taken on a pencil.

The next step is to remove the defective driver files. To do this, hold down the F8 key when starting the computer, start the system in safe mode (Safe Mode) and then eliminate the failed component using standard Windows tools. Then you will need to open the console again and enter the instruction verifier.exe /reset to deactivate the Driver Verifier Manager application. It is important to note that entering the last command is also required if the computer boots successfully, indicating that there are no problematic drivers.

For more background information on this subject, see the article "Using the Driver Verifier to Diagnose Problems with Windows Drivers (Advanced Users)" on the Microsoft Support site.


Sometimes hardware-related DRIVER_VERIFIER_DETECTED_VIOLATION blue screen errors can be caused by memory (RAM) corruption. If you're experiencing random computer restarts, boot beeps, or other computer problems (in addition to 0xC4 BSOD errors), it's highly likely that memory corruption is present. In fact, almost 10% of Windows application crashes are caused by memory corruption.

If you have recently added new memory to your computer, we recommend removing it temporarily to make sure it is not causing the DRIVER_VERIFIER_DETECTED_VIOLATION error. If this action fixed the BSOD, then that is the source of the problem, and therefore the new memory is either not compatible with some of your hardware or is corrupted. In this case, you will need to replace new memory modules.

If you haven't added any new memory, the next step is to run a diagnostic test on your computer's existing memory. A memory test allows you to scan for severe memory failures and intermittent errors that may be causing your blue screen of death 0xC4.

While recent versions of Windows include a RAM test utility, I highly recommend using Memtest86 instead. Memtest86 is a BIOS-based test software, unlike other test programs that run in a Windows environment. The advantage of this approach is that the utility allows you to check ALL operating memory for DRIVER_VERIFIER_DETECTED_VIOLATION errors, while other programs cannot check memory areas occupied by the program itself, the operating system, and other running programs.

We warn you that any experiments with drivers are dangerous and can damage the system. It is better to make a backup of the system in advance and then not cross your fingers by removing another suspicious driver from Windows.

And as soon as they do not scold Windows from Microsoft, calling the poor thing both slow and buggy and even unstable. Only now, no one is in a hurry to refuse it, and in general it is unlikely that they will ever refuse it. Therefore, instead of scolding poor developers and spreading a meaningless flame, it would be good to figure out: why, in fact, is the system buggy? I'll tell you a little secret. In the notorious screens of death and unstable work Windows in the vast majority of cases, third-party drivers are to blame, and the operating system itself has absolutely nothing to do with it. Now we will tell you how to detect such drivers and remove them from the system.

Driver design defects can be of a very different nature: from falling into the blue screen of death ( BSOD- Blue Screen of Death) and to the slowdown of the computer and the strange behavior of some application applications that are not at all related to the driver.

The blue screen of death is remarkable (without any irony!) in that it clearly signals the presence of a serious problem and gives a tip where to dig. Often (but not always) the name of the "guilty" driver is displayed directly in the upper right corner of the blue screen of death. However, it may not be there or, even worse, the name of a completely foreign driver may be there.

So, for example, one fairly common video card driver Matrox G450 tends to destroy the underlying structures of the graphics subsystem Windows 2000 , resulting in the BSOD showing the name of the system driver win32k.sys, which implements a significant part of the USER and GDI functions and which, of course, has nothing to do with it. So the interpretation of the testimony of the blue screen of death is magic, and intuition, and science, and art - a little of everything.

In addition to driver defects, blue screens of death can also be caused by hardware failures, such as an overclocked processor, faulty RAM, a crooked hard drive controller, a PCI card not fully inserted into the slot, a bad contact in one of the connectors, a bad power supply, a swollen electrolytic capacitor on motherboard. And the latter pout for various reasons: due to overheating from a nearby processor, lack of ceramic capacitors, “underreported” by the manufacturer (as a result of which the HF component goes through the electrolyte and heats it up), finally, due to leakage of key transistors in the node stabilizer. Therefore, before chopping wood, it is necessary to make sure that the iron on which we sit is fully functional. And how can this be done?

Showdown with iron

Blue screens of death caused by hardware failures are spontaneous, appearing unpredictably and regardless of any specific user actions. Application applications also begin to issue critical errors in a variety of places, and error codes, addresses and other information issued by the system will be different in all cases! By the way, drivers that process asynchronous requests from I/O devices, such as wireless networks, behave almost exactly the same way. Blue screens of death caused by defective drivers tend to occur when performing a certain set of actions and contain more or less permanent information.

To remove all suspicions from the hardware, it is enough to connect another hard drive to the system, install a pristine clean disk on it. Windows and work on it for a while. If the blue screens of death do not disappear, then, indeed, the hardware is to blame and it's time to change it. The search for defective components is a topic for a separate discussion, which we will leave for the next time, but for now, having rolled up our sleeves, we will come to grips with these insidious drivers.

Firewood without a certificate immediately into the furnace

The entire set of tools required for driver development ( DDK– Driver Development Kit), Microsoft distributes for free along with its accompanying documentation. Drivers, sometimes very buggy and unstable.

To prevent such chaos from happening, Microsoft back in ancient times, it introduced a procedure for certifying drivers for compliance with the requirements for them, after which a digital signature is issued to the driver. Or ... not issued, and he went for revision. And although certification is just a formal procedure that does not guarantee the absence of fatal errors and development defects, it still eliminates some of the frankly "pioneer" drivers.

Ideally, only digitally signed drivers should be kept in the system. And although a digital signature is not an insurance policy, its presence already indicates a certain level of development culture. Drivers that are not digitally signed are worse than a cat in a poke and should be eliminated whenever possible (especially since many of them are malware installed by rootkits or aggressive defense mechanisms that penetrate deep into the system and cause it to become unstable). ). In short, it will not breed demagogy, but let's try to answer one simple question: how to make a list of drivers without a digital signature?

The utility will help us with this. sigverif.exe, included in the standard operating system delivery set and located in the WINNT\System32 directory. Run it and see the dialog box. We press the “Advanced” button and in the “Search” tab we set up the selection criteria by moving the radio button from the position “Notify about unsigned system files” (where it vegetated by default) to the position “Search for other files not signed with a digital signature”. After that, in the “Search Options” open the “Search for files of the following type” box and select “*.sys”, and below we indicate the folder to search for “C: \ WINNT”, be sure to check the box “Include subfolders”.

In fact, strictly speaking, drivers are not required to have the sys extension and are far from always limited to the WINNT directory, being in the directories of "their" applications, and some applications even store drivers ... inside themselves! Immediately after launch (or at any other time), they save the file to disk in the current or temporary directory, load the driver into memory and ... immediately delete it from disk! Not only malicious viruses do this, but also quite respectable programs, such as some utilities of Mark Russinovich, a well-known Windows researcher.

Therefore, for the purity of the experiment, it does not hurt us at all to get a list of the drivers currently in memory and compare them with the drivers located on the disk. The words "at the moment" are key, since loading / unloading drivers can happen for free without rebooting the operating system. It is advisable to perform this operation several times by running the drivers.exe command line utility, which is part of the DDK, which can be downloaded from the Microsoft server. Launched without any command line switches, the utility drives.exe dumps all the information on the screen, which is not good, since there are usually a lot of drivers in the system and they do not fit on the screen. However, religion allows us to redirect the output stream to a text file ( drivers.exe > file-name.txt ), opened by any text editor - even Word, even notepad. Then it remains only to select a vertical block (which notepad does not allow) and get a list of drivers. Straight from the operating system kernel!

If at least one of these drivers is missing in the C:\WINNT\ directory, then its digital signature will not be verified! Naturally, such a driver immediately attracts attention, and we have a reasonable question: where does it come from? First, we scan all directories on the disk; if it's not there, set a breakpoint on Soft-Ice's CreateFileW function and look at the arguments passed to it. Sooner or later, we will meet our buggy driver, after which all that remains is to look at the lower right corner of the Soft-Ice screen, where the name of the process that created it is displayed. For more details, see the book “Techniques for Debugging Programs Without Source Codes”, an electronic copy of which can be found on the ftp- or http-server nezumi.org.ru, as well as on our disk. And we continue to torment the utility sigverif.exe.

After clicking on “OK”, “Start”, a “thermometer” will appear on the screen, showing the progress, and the hard drive will begin to rustle with all its heads that it has. Upon completion of the work, a list of drivers without a digital signature will be compiled and displayed on the screen.

Some hotheads suggest, in order to cleanse the system of heresy, to remove all unsigned drivers - then, they say, all problems will be removed like a tail. And how can this be done? The most rude solution is to simply take and delete them from the disk via FAR or Explorer (of course, with administrator rights!). But the consequences of such an operation can turn out to be very deplorable, and it is better, by right-clicking on the driver icon in Explorer, to find the name of the manufacturer in the "Properties", by which you can determine which application / piece of hardware installed this driver, and uninstall it in a civilized way. True, there is one “but”.

The following figure highlights the driver g400m.sys, which comes with the Matrox G450 card, and although Matrox is not a weak company at all, it did not receive a digital signature (either Microsoft did not give it, or Matrox itself did not want to bother). Naturally, after removing it from the system, you will have to forget about the SVGA mode. You can, however, go to the Matrox website by downloading the latest driver version (it is already digitally signed). Only now ... both the signed and unsigned versions contain many fatal errors, in particular, as a result of a combination of certain circumstances when trying to switch to overlay mode, the system crashes into a BSOD as the driver tries to free up already freed memory.

Thus, the presence / absence of a digital signature in itself does not mean anything, and even if we use only signed drivers, this does not give us any guarantees of stability.

This is where we move on to the second part of the article, namely, testing drivers in conditions close to combat.

We arrange a real test for firewood

The DDK includes a wonderful utility driver Verifier, which creates the most severe conditions for drivers, bordering on extreme and suicide, in which the probability of failure is maximum, and the name of a defective driver is determined with the highest accuracy (even if it does not suffer due to development defects, but destroys the data structure of other drivers).

It is important to note that driver Verifier It is not a cure, but only a diagnostic tool. It still won’t save you from failures (on the contrary, it will increase their intensity by a couple of orders of magnitude), but it will help to identify the “mean” driver with a sufficient degree of certainty.

So, run verifier.exe, see the window driver Verifier manager, go to the Setting tab and move the radio button to the Verify all drivers position, after which we press the “Preferred Setting” button, which sets the following types of checks (verification type):

  • Special pool- the checked drivers will be allocated a special memory area for allocation, which does not work very fast, but is able to detect most types of destruction of its own and other people's data.
  • force IRQL checking. IRQL stands for Interrupt Request Level. The most common mistake that driver developers make is trying to access memory at an IRQL that the swap manager does not work on. And if the required page suddenly turns out to be forced out to disk, the system will turn into a blue screen with the inscription "IRQL_LESS_OR_EQULAR". Forcing this mode forces the driver pages to disk, so that the development defect manifests itself in 100% of cases.
  • low resource simulation it is useful to install it in order to see how the driver will behave in case of a catastrophic lack of system resources, but this can not be done, but it is better to leave the Pool tracking checkbox (tracking the correctness of handling the memory pool). Input / output errors (I / O verification) make up an insignificant part of all errors, so the position of this checkbox is, in general, completely uncritical.

Having finished with the choice of settings, we press the button "Apply" (apply) and, as we are offered, we reboot.

As soon as the boot starts, the system will noticeably slow down, which it should, since the kernel does a lot more checks than usual. When errors are found, a blue screen of death flashes with the name of the driver and some other information useful for developers, but useless for us. All we can do is update the driver to the latest version or stop using the program (hardware) that uses it. Actually, we have a little more options for lighting raw firewood, but more on that later.

You can find out the verification status at any time by running verifier.exe. The Driver Status tab lists the status of all detected drivers with an explanation of the current situation. The Loaded status means that this driver has been loaded and tested at least once (but perhaps not completely, that is, not all sections of the driver have been worked out). The Unloaded status means that the driver has been loaded, checked (possibly partially) and unloaded by the system/program using it or by its own will. The latter is especially typical for drivers left over from equipment that was removed by barbarically pulling expansion cards out of the slot, that is, without performing an uninstall. The surviving driver scans the bus, trying to find "its" equipment, breaks off with the search, and then unloads itself from memory, by the way, slowing down the system boot (sometimes very significantly) and conflicting with other drivers. Moral: the equipment from the system must be removed according to all the rules! However, not every Unloaded status is a sign of an abnormal situation, and before deleting a driver with such a status, you need to figure out what kind of reindeer it is and where it came from.

The Never Loaded status indicates that this driver has not yet been loaded, which means that it has not been verified, therefore, you must wait while launching various programs that may be associated with it. However, some drivers (especially incorrectly uninstalled ones) are not loaded and, accordingly, are never checked.

After working with the system in the hard test mode for some time (from several hours to several days), we will identify almost all the defective drivers that we suffered from earlier, and write down their names on a piece of paper.

You can return the system to normal mode (that is, without additional checks that eat up performance) using the same verifier. We return to the Setting tab, move the radio button to the Verify selected drivers position (in this case, no driver should be selected), click on “Reset All”, then on “Apply” and reboot. Everything! The system is now running at normal speed, but no checks.

What to do with raw firewood?

But really, what can be done with a defective driver? Hackers who know how to hold a debugger in their hands, if they have enough free time, can disassemble it (fortunately, drivers are usually small in size), find an error, and come up with a way to fix it, but ... this is too laborious.

Throwing away the driver (along with the hardware/program that uses it) is also not an option. Although if it is known that the sound card of an unfamiliar Chinese manufacturer worth $20 is to blame for the blue screens of death, then we have quite a weighty motivation to replace it with something more worthy. But this, in fact, is clear to everyone and does not need additional comments.

But not everyone knows that a huge number of crashes and blue screens of death is due to the fact that a driver developed (and tested) in a single-processor environment is installed on a dual-processor machine. By "dual processor" here we mean both a real platform with two stones, and Hyper-Threading / multi-core processors. It is known (and confirmed by a large number of tests) that two processors are absolutely useless for a home computer, since in the vast majority of applications there is practically no increase in performance.

Therefore, if the system is unstable, and for one reason or another it is not possible to get rid of the defective driver, you can try to get into BIOS Setup, turning your “virtual dual-processor” machine into a single-processor one. A similar effect can be achieved by opening the boot.ini file (on computers with Windows NT/2000/XP it is located in the root directory of the logical drive on which the system is installed) and adding the /ONECPU key to it, and then reboot in the hope that the errors will disappear.

Listing 1

An example of a typical boot.ini file


timeout=30

multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows 2000 Pro" /fastdetect /SOS

Listing 2

We configure the system to use only one processor from all available


timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows 2000 Pro" /fastdetect /SOS /ONECPU

But on Windows Vista there is no boot.ini file, and while there is a (temporary) option to configure its boot settings with a utility, Microsoft plans to eliminate this loophole entirely, leaving only BIOS Setup. However, as regards Vista, then by the time they switch to it, driver developers will most likely acquire multiprocessor machines (since there simply won’t be any others on sale) and will test their creations in a multiprocessor environment.

Another subtle point. Remember, we said above that the most common mistake made by driver developers is accessing preempted memory at an IRQL level at which the swap manager does not work, and if the requested page is not in memory, a crash occurs? The obvious solution here would be to increase the RAM to the amount at which the displacement of pages to disk practically does not occur. At current prices for memory, almost everyone can afford to buy a couple of new "dice". But there is a more accessible (and more elegant) solution to the problem. If the parameter DisablePagingExecutive, located in the following registry branch HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\MemoryManagement, is equal to one (zero by default), nuclear components will not be displaced. Therefore, we simply launch the "Registry Editor", change this treasured parameter and reboot (the changes take effect only after a reboot), hoping that this will help solve the problem of failures.