1. Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

Techniques for ferreting out BAD DRIVERS, w/ existing Windows tool driver verifier

Discussion in 'General Software' started by Alec§taar, Jun 5, 2006.

  1. Alec§taar New Member

    Joined:
    May 15, 2006
    Messages:
    4,677 (1.53/day)
    Thanks Received:
    94
    Location:
    Someone who's going to find NewTekie1 and teach hi
    See subject line - & how to do it, with an already EXISTING tool in your Windows 2000/XP/Server 2003 OS!

    The tool is called "Driver Verifier" (verifier.exe), & here is HOW to go about using it to debug "kernel mode" programs like drivers you suspect MAY be messing you up in terms of stability & uptime, etc.:

    Once inside verifier.exe?

    You'll see a SETTINGS group (at least this is what I see in Windows Server 2003, there are diff.'s iirc, in Windows 2000 for instance, like tabbed groups instead).

    Once you setup a set of drivers to check on (you can go after them ALL, or only some, OR just signed vs. unsigned ones, etc. - the first groupbox you see has settings for this, check thru them all & see what I mean)?

    E.G. -> "Drivers designed for older Windows OS", vs. "Automatically select unsigned drivers" (iirc, ones NOT passed thru the WHQL by MS, which pretty much imo, assures they will be OK)

    You'll note a bunch of drivers listed as currently eligible for debugging.

    (These generally aren't just for hardware, but essentials for the OS loading).

    Select the SPECIAL POOL check box in the Verification type pane section. This makes the OS force the driver to allocate memory in areas surrounded by NOTHING else (to check if the driver writes outside of its 'boundaries', which can cause it to overwrite other programs/drivers/kernel modules, causing BSOD's etc.).

    Selecting another option, POOL TRACKING, will check for "memory leaks" that drivers allocate, but never de-allocated, as well.

    Using the Force IRQL checking option helps also in diagnosis imo, because it checks for a driver trying to access pageable memory areas (parts of programs &/or data paged to disk in the pagefile.sys), which is another problem possible area also.

    I/O Verification/Enhanced I-O Verification are also good ones as well!

    (IIRC, in older models of verifier.exe (circa 2000 & possibly XP), Setting it to level 2 is recommended).

    It checks for I/O violations & identifies them.

    Deadlock detection's ANOTHER good one to look into + use as well. IIRC, it is for checking on "race conditions" between drivers, but THIS one I am a WEE bit hazy on.

    Disk Integrity Checking's, iirc, another one to use because it checks if the driver's .sys files are loaded from disk in GOOD working order, uncorrupted by filesystem problems, etc.

    (The Low Resources option? You can try it, but it REALLY slows your OS down, lots. BUT, it can also help "ferret-out" which drivers may be "weak" because the verifier app randomly reports 'out-of-memory' conditions to the kernel modules responsible for memory mgt. in the OS kernel).

    Once you're done here? Reboot, so it ALL takes... & let it ride, + find out if you have ANY "bum drivers" present.

    IMPORTANT POINTS:

    The "Create Custom Settings for developers" applies largely to many of the techniques listed & settings above, & that's the ONE to use imo & experience!

    You can go w/ the 'prebuilt' INITIAL group box page's checkboxes too, or even the one called "predefined settings" in the developer analysis 2nd page but I tend to use the more "manual" one (SELECT INDIVIDUAL SETTINGS FROM A FULL LIST), because it illustrates JUST what to check on & allows you greater control imo.

    ... & remember: You CAN "undo" running VERIFIER period if needed, just by re-running it again & unsetting your use of it...

    APK

    P.S.=> So, in a nutshell:

    What it does, basically?

    Is treat kernel mode modules like drivers pretty much like user-mode apps (which are CLOSELY monitored, unlike drivers (but this has gotten better via DDK templates from MS being proven & more like WHQL testings))!

    As stated above, it watches PLUS enforces their memory areas read/written to, + where they are located, for debug purposes.

    It also watches how much memory is used & when/where/how, especially for "leaks" (left over memory areas the driver called on & allocated) which may be left over & 'hanging/orphaned' still.

    Hope it helps you guys understand how to figure out if drivers you have are operating "under-par" on you... apk
     

Currently Active Users Viewing This Thread: 1 (0 members and 1 guest)

Share This Page