Utility Driver Verifier is included in all versions of Windows, starting with Windows XP, and allows you to check drivers, identify problem drivers that cause blue screen of death (BSOD- Blue Screen of Death) and write detailed information about the problem driver into a memory dump for further analysis. The utility exposes the checked drivers to different " stress tests”, Simulating various extreme conditions: lack of memory, I / O control, IRQL, deadlocks, DMA checks, IRP checks, etc. situations that rarely occur on productive systems are simulated, and the behavior of the driver in them is monitored. The purpose of the utility is to identify situations in which the driver can lead to an abnormal termination of the system with BSOD.
The executable file of the Driver Verifier utility is called Verifier.exe and is located in the% windir% \ system32 directory. There are two options for using the utility: from the command line or using the graphical interface.
To enable Driver Verifier mode in Windows 8, launch Driver Verifier by typing
Verifier
In the task list, select Create custom settings (for code developers) and press Next.
Make sure the options are selected Standard settings, Force pending I / O requests and IRP Logging... Click on Next.
Next select.
Sort the contents of the table by clicking on the "Provider" column heading and select the drivers you want to test from the list of drivers. In our example, we will run a check for all drivers that are not a developer MicrosoftCorporation... We selected drivers: e1g6032e.sys (Intel) and lsi_sas.sys (LSI).
Note... The presence of a Microsoft digital signature in the driver indicates that the driver has been tested in a certain way for stability and its code has not been modified after that. That is why it is not recommended or used.
It remains to press Finish and an informational window will appear stating that you need to reboot the system for the changes to take effect.
Advice... You can also enable driver check mode from the command line. For example, to run Driver Verifier with default settings for the myPCDriver.sys driver, the command would look like this:
Verifier / standard / driver myPCDriver.sys
After rebooting, the system boots in driver check mode. Driver Verifier runs in the background, performing various types of error testing on selected drivers. Use your computer as usual and wait for the BSOD to appear. If you know what actions previously led to an abnormal system shutdown, repeat them. In the event of a BSOD, it is necessary to copy a memory dump file (by default, they are saved in the C: \ Windows \ Minidump \ *. Dmp directory) and or an equivalent.
Important! After activating the driver debugging mode using Driver Verifier, this mode will work until it is forcibly disabled.
In the event that the problem has not recurred within 1-2 days, then with a certain degree of certainty it can be concluded that the drivers being checked are not the cause of the system crash and the check mode can be disabled for them.
Advice... Using the Windows Driver Verifier significantly slows down Windows, so it is not recommended to use this mode all the time.
You can disable Driver Verifier from the command line:
Verifier / reset
Or from the graphical interface by selecting the item Delete existing settings.
If you cannot log in to the system in normal mode, you can also disable debug mode from safe mode.
In the event that the system does not boot in safe mode, try deleting the following keys in the registry by booting from the boot disk:
- HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ Memory Management \ VerifyDrivers
- HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ Memory Management \ VerifyDriverLevel
You can check the current status of Driver Verifier as follows.
Sometimes hardware-related DRIVER_VERIFIER_DETECTED_VIOLATION blue screen errors can be due to memory (RAM) corruption. If you experience random computer restarts, startup beeps, or other computer malfunctions (in addition to BSOD 0xC4 errors), then it is very likely that there is memory corruption. In fact, nearly 10% of Windows application crashes are caused by memory corruption.
If you've recently added new memory to your computer, we recommend temporarily removing it to make sure it isn't causing the DRIVER_VERIFIER_DETECTED_VIOLATION error. If this action resolved the BSOD, it means that this is the source of the problem, and, therefore, the new memory is either incompatible with some of your hardware, or is corrupted. In this case, you will need to replace new memory modules.
If you did not add new memory, the next step is to carry out a diagnostic test of the available computer memory. The memory test allows you to scan for severe memory failures and intermittent errors that could be causing your 0xC4 blue screen of death.
Although recent versions of Windows contain a utility for checking RAM, I highly recommend using Memtest86 instead. Memtest86 is a BIOS based test software unlike other test programs that run in the Windows environment. The benefit is that it allows you to test ALL of your memory for DRIVER_VERIFIER_DETECTED_VIOLATION errors, while other programs cannot test the section of memory occupied by the software itself, the operating system, and any other running programs.
Indicates a system driver that is unlikely to be causing the problem (for example, win32k.sys). In this case, a serious analysis of the dump will be required, which requires very deep knowledge and experience in this area. However, you can check the drivers yourself using the operating system's built-in validator. Verifier.exe... While it is detailed in the Microsoft Knowledge Base article, Using the Driver Verifier to Troubleshoot Windows Driver Issues, the material presented is at a rather complex technical level. Below is a brief description of the steps you need to follow to validate the drivers.
On this page
Getting Started with Driver Verifier
On the menu Start — Execute(or Start — Search) enter verifier and press Enter. The Driver Verifier starts. Select item Create custom parameters (for program code) and press the button Further.
Select individual parameters from the complete list and press the button Further.
In the next step, check all the boxes except Simulating 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.
Find updated drivers
You need to check if there are updated drivers.
- If you see an application driver listed, visit the manufacturer's website to see if the application has been updated. If there is no updated version, you can try uninstalling the application (you can always reinstall it later). If the critical errors stopped, that was the cause.
- If you see a device driver listed and are running Windows Vista, use Windows Update to find new drivers. This method works well for Windows Vista because many device manufacturers partner with Microsoft to provide their drivers for download using Windows Update. In the control panel, select Windows Update and check for updates to your device driver. If a driver is found, install it.
- 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 problems finding drivers, please visit the Find Drivers, Firmware and Manuals forum on OSzone.net.
After updating the application or driver, close the Driver Verifier window, pressing the button Cancellation(but not Further) ... Restart your computer and continue working in the operating system. If the fatal error no longer occurs, you have fixed it by updating the driver.
Removing drivers
If no new drivers are found, try uninstalling the driver.
Attention! Removing drivers leads to inoperability of devices. After a reboot, at best, the operating system will install the appropriate driver from its own driver store. If you are not sure if you need 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 unsigned drivers
Attention! After checking unsigned drivers, the system may not boot (below is described how to proceed in such a situation).
If you do not 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 and then restart your computer. If after rebooting you see a blue screen with an error, 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 has booted normally, the check for unsigned drivers was successful - they are not the source of the problem. You can see a list of tested drivers by running verifier.exe .
Since unsigned drivers are not the cause of the fatal error, you need to check other drivers.
Selective Driver Verification
If no unsigned drivers are found or the validation does not reveal any problems, you will have to perform a spot check of the drivers. In this case, in the window below, select Select 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 as it will take a lot of time and system resources to check them.
Therefore, the check may have to be done in several stages. The step-by-step sequence for selecting drivers can be as follows:
- Recently updated drivers or those that typically cause problems (antivirus, firewall, virtual disk drivers).
- Non-Microsoft Drivers.
- A group of 10 to 15 drivers at a time.
Select the drive where the operating system is installed and click the Ready and then restart your computer.
Attention! After checking the drivers, the system may not boot (below is described how to proceed in such a situation).
If after rebooting you see a blue screen with an error, 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 tested drivers by running verifier.exe and choosing in the first step the item Display information about currently tested drivers.
Now select the next driver group and check again.
All drivers are verified - what's next?
If the verification of all drivers succeeds, I must take off my hat to your patience and perseverance. Chances are, drivers are not the cause of a critical error occurring on your system. It is possible that the problem lies in the hardware of your computer - for example, in a faulty hard disk or RAM, or the power supply unit has insufficient power to ensure the operation of all devices. There may be other hardware problems that cannot be detected by checking the drivers.
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, removing another suspicious driver from Windows.
And as soon as they do not scold Windows from Microsoft, calling the poor thing at the same time nerdy, and buggy and even unstable. Only now no one is in a hurry to give it up, and in general it is unlikely that they will ever give it up. Therefore, instead of scolding poor developers and throwing a meaningless flame, it would be good to figure out: why, in fact, is the system buggy? Let me tell you a little secret. In the notorious screens of death and precarious 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 find such drivers and remove them from the system.
Defects in driver design can be of a very different nature: from falling out into the blue screen of death ( BSOD- Blue Screen of Death) and to the slowdown of the computer and the strange behavior of some applications that are completely unrelated 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 from 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 extraneous driver may be there.
So, for example, one fairly common driver from a video card Matrox G450 tends to destroy the underlying structures of the graphics subsystem Windows 2000 , as a result of which the BSOD displays 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 bit of everything.
In addition to driver defects, blue screens of death can also be caused by hardware failures, for example, an overclocked processor, faulty RAM, a crooked hard disk controller, a PCI card not fully inserted into the slot, non-contact in one of the connectors, a bad power supply, swollen electrolytic capacitor on motherboard. And the latter are sulking for various reasons: due to overheating from a nearby processor, a lack of ceramic capacitors "unsuitable" by the manufacturer (as a result of which the RF component goes through the electrolyte and heats it up strongly), finally, due to the leakage of key transistors in the node stabilizer. Therefore, before chopping wood, you need to make sure that the iron on which we are sitting is completely intact. How can this be done?
Showdown with iron
Blue screens of death caused by hardware failures are spontaneous in nature, appearing unpredictably and independently of any specific user actions. Applications are also starting to generate critical errors in many different places, and the error codes, addresses, and other information generated by the system will be different in all cases! By the way, drivers that handle asynchronous requests from I / O devices such as wireless networks behave in much the same way. Blue screens of death caused by defective drivers, as a rule, 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 virgin Windows and work on it for a while. If the blue screens of death do not disappear, then, indeed, the iron is to blame and it's time to change it. The search for defective components is a topic for a separate conversation, which we will leave for the next time, but for now, rolling up our sleeves, we will come to grips with these insidious drivers.
Firewood without a certificate directly into the firebox
The entire set of tools required for driver development ( DDK- Driver Development Kit), Microsoft distributes free of charge along with 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 imposed on them, after which a digital signature is issued to the driver. Or ... not issued, and he was sent for revision. And although certification is just a formal procedure that does not guarantee the absence of fatal errors and development defects, it still filters out some of the frankly "pioneer" drivers.
Ideally, only digitally signed drivers should be kept on the system. And while a digital signature is not an insurance policy, its presence already indicates a certain level of development culture. Drivers without a digital signature are worse than a cat with a cat in a bag, and should be disposed of whenever possible (especially since many of them are malicious programs installed by rootkits or aggressive defense mechanisms that penetrate deeply into the system and cause its instability ). In short, it will not breed demagoguery, but we will 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 delivery set of the operating system and located in the WINNT \ System32 directory. We launch it and see a dialog box. Press the "Advanced" button and in the "Search" tab set up the selection criteria by moving the radio button from the "Notify about unsigned system files" position (where it stagnated by default) to the "Search for other files not signed with a digital signature" position. After that, in the "Search parameters" open the box "Search for files of the following type" and select "* .sys", and below we indicate the folder for the search "C: \ WINNT", be sure to check the box "Including subfolders".
Actually, strictly speaking, drivers are not required to have the sys extension and are not always limited to the WINNT directory, being in the directories of "their" applications, and some applications even store drivers ... inside themselves! Immediately after starting (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 the disk! This is done not only by malicious viruses, but also by quite respectable programs, like some utilities of the famous Windows explorer Mark Russinovich.
Therefore, for the purity of the experiment, it will not hurt us at all to get a list of drivers currently in memory and compare them with the drivers located on the disk. The words "at the moment" are key, since the loading / unloading of drivers can be done for free without rebooting the operating system. It is advisable to perform this operation several times by running the drivers.exe command line utility included in 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), which can be opened by any text editor, be it Word or notepad. Then all that remains is to select a vertical block (which notepad does not allow) and get a list of drivers. Straight from the kernel of the operating system!
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 the 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 come across our buggy driver, after which it remains only to look at the lower right corner of the Soft-Ice screen, where the name of the process that spawned it is displayed. For more details, see the book "Technique 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, displaying the progress of the progress, and the hard disk will begin to rustle with all its heads, which it only 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, it will remove all problems like a tail. How can this be done? The crudest solution is to simply take and delete them from the disk via FAR or Explorer (of course, having administrator rights!). But the consequences of such an operation can turn out to be very dire, and it is better, by right-clicking on the driver icon in the explorer, to find the manufacturer's name in the Properties, by which you can determine what application / hardware installed this driver, and uninstall it in a civilized way. True, there is one "but" here.
The driver is highlighted in the figure. g400m.sys, which comes with the Matrox G450 card, and although Matrox is not a frail company at all, it did not receive a digital signature (either Microsoft didn’t give it, or Matrox itself didn’t 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 signed and unsigned versions contain many fatal errors, in particular, as a result of certain circumstances, when trying to switch to overlay mode, the system crashes into a BSOD, as the driver tries to free the already freed memory.
Thus, the presence / absence of a digital signature does not in itself mean anything, and even if we use only signed drivers, this does not give us any guarantees of stability.
This is where we pass 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 great 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 the defective driver is determined with the highest accuracy (even if due to development defects it does not suffer itself, but destroys the data structure of other people's drivers).
It is important to note that Driver Verifier is not a medicine, but only a diagnostic tool. It will still not 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 "sneaky" driver with a sufficient degree of reliability.
So, run verifier.exe, we see a window Driver Verifier Manager, go to the Setting tab and move the radio button to the Verify all drivers position, then press the "Preferred Setting" button, which sets the following verification types:
- Special pool- the checked drivers will be allocated a special memory area for allocation, which does not work very quickly, but is capable of detecting most types of damage to their own and other people's data.
- Force IRQL checking. IRQL is the Interrupt Request Level. The most common mistake driver developers make is trying to access memory at an IRQL where the swap manager does not work. And if the required page is suddenly pushed to disk, the system will turn into a blue screen with the inscription "IRQL_LESS_OR_EQULAR". Forcing this mode forcibly pushes 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, however, this may not be done, but the Pool tracking checkbox (tracking the correctness of handling the memory pool) is better left. I / O verification errors make up an insignificant part of all errors, so the position of this checkbox is generally completely uncritical.
Having finished with the choice of settings, we press the "Apply" button and, as we are offered, we reboot.
Immediately after the boot starts, the system slows down noticeably, which it should be, since the kernel performs 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 starting raw firewood, but more on that later.
You can find out the status of the check at any time by running verifier.exe. The Driver Status tab lists the statuses 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 parts of the driver have time to run). The Unloaded status prepares that the driver has been loaded, verified (possibly partially) and unloaded by the system / program using it or of its own accord. The latter is especially true for drivers left over from equipment that was removed by barbarously pulling the expansion cards out of the slot, that is, without performing uninstallation. The surviving driver scans the bus, trying to find "its" hardware, breaks off with a search, and then unloads itself from memory, by the way, slowing down the system load (sometimes very significantly) and conflicts with other drivers. Moral: the equipment must be removed from the system according to all the rules! However, not every Unloaded status is a sign of an abnormal situation, and before removing 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, and therefore has not been tested, therefore, you need to wait, launching various programs that may be associated with it. However, some drivers (especially incorrectly uninstalled ones) are not loaded and, accordingly, never checked.
Having worked with the system in the hard check mode for some time (from several hours to several days), we will identify almost all defective drivers from which we suffered earlier, and write 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. Return to the Setting tab, move the radio button to the Verify selected drivers position (no driver should be selected), click on "Reset All", then on "Apply" and reboot. Everything! The system is now operating at normal speed, but without checks.
What to do with raw wood?
But really, what can be done with a defective driver? Hackers who know how to hold the debugger in their hands, if they have enough free time, can disassemble it (since the drivers are usually small in size), find a bug, and come up with a way to fix it, but ... this is too time consuming path.
Throwing away the driver (along with the hardware / program that uses it) is also not an option. Although if it is known that a $ 20 sound card from an unknown Chinese manufacturer is to blame for the blue screens of death, then we have quite a strong 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 are 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 there is practically no increase in performance on the vast majority of applications.
Therefore, if the system is unstable, and you cannot get rid of the defective driver for one reason or another, you can try to get into BIOS Setup, turning your “virtual two-processor” machine into a one-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 disk on which the system is installed) and adding the / ONECPU switch 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 out of 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) opportunity to configure its boot settings using a special utility, Microsoft plans to completely remove this loophole, so that only BIOS Setup remains. However, as for Vista, then by the time of switching to it, driver developers will probably acquire multiprocessor machines (since there simply will not be others on sale) and will test their creations in a multiprocessor environment.
Another subtle point. Do you remember that we said above that the most common mistake made by driver developers is accessing preemptive memory at the IRQL level at which the paging manager does not work, and if the requested page is not in memory, it crashes? The obvious solution here would be to increase the RAM to the extent that practically no paging to disk occurs. At current prices for memory, almost everyone can afford to buy a couple of new "dies". But there is also a more accessible (and more elegant) solution to the problem. If the parameter DisablePagingExecutive located in the next registry branch HKLM \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ MemoryManagement, equals one (zero by default), nuclear components will not be displaced. Therefore, we simply launch the "Registry Editor", change this cherished parameter and reboot (the changes take effect only after a reboot), hoping that this will help solve the problem of crashes.
A driver is a program that is required for the operating system and various software applications to interact with the hardware devices connected to it. Hardware components such as sound, video cards, printers, scanners and they all need a compatible driver to work properly.
All device drivers are designed for specific operating systems. For example, Windows XP drivers will differ from Windows Vista drivers. Therefore, you need to take extra precautions when installing and updating device drivers, as installing the wrong or incompatible drivers may not only damage your device, but also your system.
Common Causes of Driver Errors
Some common causes of driver errors are listed below:
- You are trying to use a hardware device that is not properly connected to the computer.
- Two or more drivers on the system are incompatible with each other.
- The driver or drivers are being installed incompatible with your system.
- There are unnecessary or outdated drivers on the PC.
Steps to fix driver errors
The first step in fixing a driver error is to make sure the device is properly connected to your system. Many devices give connection errors, so make sure your device is connected to your system correctly. Next, you need to make sure there are no problems with the drivers. You can do this using the Device Manager utility that comes with your Windows computer system. You can open Device Manager by directly running devmgmt. msc
from the command lineStart> Executego.
When you open Device Manager, you will see a list of all devices connected to your system. You can easily identify the defective file because it will be marked with a yellow triangle with an exclamation mark inside. Right-click on a device to open its properties dialog box. In the properties dialog, check the section Device status in the tab Are common... Drivers are displayed on the Drivers tab of the Properties window. Here, do one of the following tasks:
- Check and Install Driver Updates: Outdated drivers are one of the main causes of driver errors. To resolve this issue, click the Update Driver.The hardware upgrade wizard will open. You can use the wizard to update the driver. It is recommended that you first download the driver update and save it to a convenient location on your hard drive, and then start the update process because the update wizard will ask you for a location to install the update.
- Driver rollback: If you start getting an error message shortly after installing a new update, then it is likely that the new update has a buggy. To fix this problem, click the button Rolling back the driver to revert to your previous driver version.
- Uninstalling the driver: If there are problems with your current drivers - missing or corrupted files - the best thing you can do is click Delete to uninstall the current driver, then reinstall the driver again.
In case you are not sure what you are doing, and if you find the above fixes a little tricky, then it is recommended that you select a reliable driver scan tool. Driver Scan Tools are designed to check all device drivers and make sure they are not up-to-date. Whenever new updates are available, Driver Scanner automatically downloads and installs the best updates to your computer.