How to check your computer for driver conflicts. How to fix DRIVER_VERIFIER_DETECTED_VIOLATION blue screen errors (0x000000C4). Reading a dump file

A faulty driver can cause many problems with your computer. The main sign that your computer has a faulty driver is the blue screen of death, which is often caused by a driver being disabled.

In this article, we will tell you how you can find a faulty driver, and then update it or completely remove it.

Sometimes Windows notifies the user that one of the drivers has failed. However, it happens that the system cannot detect what the problem is, therefore it does not issue error messages, which is why it works slower or not as required. In this case Driver Check Manager(Driver Verifier) ​​creates an additional load on system drivers, thereby trying to cause a crash. If one of the drivers fails, then Driver Check Manager report a problem with a blue screen.

A warning

Before use Driver Check Manager, please note that the tool may restrict you from using your own computer. Insofar as Driver Check Manager launches a blue screen of death when it detects a faulty driver, this can cause big problems when loading Windows.

If you don't have a chance to get into Windows to disable driver testing, your computer will go into a "boot -> load -> crash" loop that's pretty hard to get out of. The Automatic Repair feature is one of the few options to access Windows, but it's best to avoid this situation.

Before using Driver Verifier, make sure you have at least one of the following escapes:

• You can go into safe mode. Entering Safe Mode before Windows starts loading is usually done by repeatedly pressing F8 while the computer is booting. However, new computers boot up so fast that you simply won't have time to press F8 at the right moment.
• You created a system restore point before using Driver Check Manager. It is also desirable to have an installation Windows disk so you can restore your computer to factory settings.

How to run the Driver Verification Manager

Before starting the instructions for use Driver Verification Manager, make sure you read the "Warning" section above. It says how to avoid endless loading of Windows.

When you are one hundred percent sure that you have an emergency exit plan, click " Windows Key + R» and enter cmd in the dialog box Run", then press " OK».

In the command window, enter:

verifier

In the popup window select " Create custom parameters (for program code)", then press " Further».

You will see a list of all the tests that you can run to verify the drivers. Select all tests from the list, except"Simulate random resource shortage" and "Additional DDI Compliance Check", then click " Further».

On the next screen select " Selectdriver names from the list" and press " Further».

Here you can select the drivers you want to test. If you don't know which driver is malfunctioning, choose all but Microsoft because they most often work without errors.

When you click " Ready”, Windows will prompt you to restart your PC. After the computer turns on, continue using it as you normally would. If you get a blue screen, pay attention to the error message and restart your computer.

Once you have identified the faulty driver, you can disable Driver Check Manager in one of two ways. You can re-open the command prompt, enter the command verifier, and select " Delete existing options».

You can also open a command prompt and type:

Verifier /bootmode resetonbootfail

After disabling Driver Verification Manager, restart your computer. If the computer does not turn on, then use one of the emergency exits that we talked about in the "Warning" section.

Output

If you think one of the drivers is malfunctioning but can't figure out which one, then Driver Check Manager will be a great help.

However, you should be prepared for the fact that the computer will not be able to turn on after testing the drivers, so consider an emergency exit, such as going into safe mode or starting a Windows restore point.

Have you ever had problems with drivers on your computer? How did you manage to find the faulty driver? Tell us in the comments below!

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 controller hard drive, a PCI card that is not fully inserted into the slot, a non-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 iron, it is enough to connect another one to the system. HDD, install on it pristine 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 demagoguery, 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. Click the "Advanced" button and in the "Search" tab set 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 specify 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 utility command line drivers.exe included in the DDK, which can be downloaded from Microsoft's 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 with Word, even with a 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 is not 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 true 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 blue screens of death are to blame sound card unfamiliar Chinese manufacturer worth $20, 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 home computer two processors are absolutely useless, 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 random access memory up to the volume 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.

If you suspect that any of the drivers does not work correctly or, after analyzing the memory dump, you have identified the driver that caused the error, then for a more thorough check of the operation of the drivers, you can independently check the drivers using the checker built into the operating system Verifier.exe.

Check for unsigned drivers.

verifier and press Enter.
2) Select an item and press the button Further.
and press the button Further.
Simulation of a lack of resources and press the button Further.
Automatically select unsigned drivers and press the button Further.

If unsigned drivers are found, the system will display a list of them, which will include the driver files and their description. Moreover, the found drivers can belong to both devices and applications. Do not close the Driver Verifier window or press any buttons yet.

Option 1: Update the program or driver.

6) Visit the website of the device manufacturer or the author of the program and download the newer version.
7) Reinstall the program or update the driver.
8) After updating the application or driver, close the Driver Checker window by clicking the button Cancel.
9) Restart your computer and continue working in the operating system.
If the system does not have errors associated with this driver, then updating the driver or program eliminated it.

Option 2: Remove the program or driver.

6.1) Remove the program that owns this driver.
6.1.1) Open Control PanelAll Control Panel ItemsPrograms and Features and uninstall the application that owns the driver.
Before uninstalling a program, make sure that you have its installation disk or that its installation is saved on your disk.

6.2) Remove the driver in Device Manager.
6.2.1) In the menu Start right click on A computer and select the item Properties.
6.2.2) Click in the list on the left on Device Manager.
6.2.3) B Device Manager find the device, right-click on it and select the item from the context menu Properties.
6.2.4) Go to tab Driver and press the button Delete.

7) After uninstalling the application or driver, close the Driver Verifier window by clicking the button Cancel.
8) Restart your computer and continue working in the operating system.

If the system does not have errors associated with this driver, then uninstalling the driver or program eliminated it.

Option 3: Check for unsigned drivers.

Attention! After checking for unsigned drivers, the system may not boot (before proceeding with further steps, read this option to the end).

6) Press the button Ready and restart your computer.

7) Restart your computer
8) Before the start Windows startup press the F8 key. When the disk selection window appears: select the disk on which you have Windows installed, press Enter, and then immediately F8.
9) Select item Safe mode
10) Open the dialog menu Run: Start ->
11) Enter command verifier.exe /reset and press Enter.

If the system booted normally, the check for unsigned drivers was successful - they are not the source of the problem.

Checking signed drivers.

1) In the start menu search bar, type verifier and press Enter.
2) Select item Create custom parameters (for program code) and press the button Further.
3) Set the radio button to Select individual options from a complete list and press the button Further.
4) Check all checkboxes except checkbox Simulation of a lack of resources and press the button Further.
5) Set the radio button to Select a driver name from the list and press the button Further.
6) Click on the column heading The supplier to sort drivers by their vendor.
7) Select the first 10-15 drivers by checking the boxes next to them in the column Verify.
Do not select all drivers at once, as checking them will take a lot of time and system resources.
8) Press the button Ready and restart your computer. If the system booted normally, the selected drivers were checked successfully - they are not the source of the problem. In this case, repeat the above steps by selecting the next 10-15 drivers.

If a blue screen with an error appears after the reboot, the problematic driver has been identified - its name will be included in the error message. In this case:

1) Restart your computer
2) Before starting Windows, press the F8 key. When the disk selection window appears: select the disk on which you have Windows installed, press Enter, and then immediately F8.
3) Select item Safe mode
4) Open the dialog menu Run: Start -> Run or press the combination Win + R
5) Enter command verifier.exe /reset and press Enter. If the check of all drivers was successful, then most likely the drivers are not the cause of the critical error that occurs on your system.

Indicates a system driver that is unlikely to be causing the problem (for example, win32k.sys). In this case, you will need a serious analysis of the dump, which requires very deep knowledge and experience in this area. However, you can check the drivers yourself using the checker built into the operating system. Verifier.exe. Although it is covered in detail in the Microsoft Knowledge Base article Using the Driver Verifier to Troubleshoot Windows Drivers, the material presented there is presented at a fairly technical level. The following is a brief description of the steps you need to follow to check the drivers.

On this page

Getting Started with the Driver Verifier

On the menu Start — Run(or Start — Search) enter verifier and press Enter. The Driver Verifier will launch. Select an item Create custom parameters (for program code) and press the button Further.

Select individual options from a complete list and press the button Further.

In the next step, check all the boxes except Simulation of a lack of resources and press the button Further.

In the next step, select Automatically select unsigned drivers and press the button Further. If no unsigned drivers are found, go to .

Unsigned drivers

If unsigned drivers are found, you will see a list of them.

Drivers can belong to both devices and applications. Do not close the Driver Verifier window or click the button Further now.

Search for updated drivers

You need to check if there are updated drivers.

1. If you see an application driver in the list, visit its manufacturer's website - the application may have been updated. If there is no updated version, you can try uninstalling the app (you can always reinstall it later). If critical errors stop, it was the cause.
2. If you see a device driver listed and you are running Windows Vista, use the windows updates to search for new drivers. This method works well for Windows Vista because many device manufacturers work with Microsoft to make their drivers available for download through Windows Update. In the control panel, select Windows Update and check for updates for your device driver. If the driver is found, install it.
3. If Windows Update doesn't offer you new drivers, visit the device manufacturer's website. Perhaps new drivers are available there. If you are having trouble finding drivers, please visit the Find Drivers, Firmwares and Manuals forum on OSzone.net.

After updating the application or driver, close the Driver Verifier window, pressing a button Cancel(but not Further) . Restart your computer and continue working on the operating system. If the critical error no longer occurs, you have fixed it by updating the driver.

Uninstalling drivers

If no new drivers are found, try uninstalling the driver.

Attention! Removing drivers causes the devices to be inoperable. After a reboot, at best, the operating system will install the appropriate driver from its own driver store. If you are unsure whether to uninstall a particular driver, do not uninstall it.

In device manager ( Start — Search / Run — devmgmt.msc — OK) find the device, right-click on it and select the item from the context menu Properties. Then go to the tab Driver and press the button Delete.

Checking for Unsigned Drivers

Attention! After checking for unsigned drivers, the system may not boot (see below how to proceed in such a situation).

If you don't want to uninstall the driver and/or want to check for unsigned drivers, in the Driver Verifier window, click Further. You will be prompted to select a physical disk.

Ready, then restart your computer. If you see a blue screen with an error after rebooting, the problematic driver has been identified - its name will be included in the error message. Enter Safe Mode and reset all driver verification options by typing in Start — Search / Run command verifier.exe /reset.

If the system booted normally, the check for unsigned drivers was successful - they are not the source of the problem. You can see a list of verified drivers by running verifier.exe .

Since unsigned drivers are not the cause of the fatal error, you need to check other drivers.

Custom driver check

If no unsigned drivers are found, or if the driver check does not reveal any problems, you will have to perform a custom driver check. In this case, in the window shown below, select the item Select a driver name from the list.

In the next step, you will be prompted to select the drivers to check. Don't select all drivers at once, since checking them will take a lot of time and system resources.

Therefore, the verification may have to be carried out in several stages. The step-by-step sequence for selecting drivers can be as follows:

1. Recently updated drivers or those that typically cause problems (antivirus, firewall, virtual disk drivers).
2. Drivers not supplied by Microsoft.
3. A group of 10 - 15 drivers at a time.

Select the drive where the operating system is installed and click Ready, then restart your computer.

Attention! After checking the drivers, the system may not boot (see below how to proceed in such a situation).

If you see a blue screen with an error after rebooting, the problematic driver has been identified - its name will be included in the error message. Restart your computer and enter safe mode by clicking F8 while loading. After logging in, reset all driver verification options by typing in Start — Search / Run command verifier.exe /reset.

If the system booted normally, the selected drivers were checked successfully - they are not the source of the problem. You can see a list of verified drivers by running verifier.exe and choosing at the first step the item Display information about current tested drivers.

Now select the next group of drivers and check again.

All drivers checked - what's next?

If the verification of all drivers was successful, I must take my hat off to your patience and perseverance. Most likely, the drivers are not the cause of the critical error that occurs on your system. It is possible that the problem lies in the hardware of your computer - for example, in a faulty hard drive or RAM, or the power supply does not have enough power to power all devices. There may be other hardware problems that cannot be detected by checking the drivers either.

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.

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