Alec§taar
New Member
- Joined
- May 15, 2006
- Messages
- 4,677 (0.71/day)
- Location
- Someone who's going to find NewTekie1 and teach hi
| Processor | DualCore AMD Athlon 64x2 4800+ (o/c 2801mhz STABLE (Ketxxx, POGE, Tatty One, ME)) |
|---|---|
| Motherboard | ASUS A8N-SLI Premium (PCIe x16, x4, x1) |
| Cooling | PhaseChange Coolermaster CM754/939 (fan/heatsink), Thermalright heatspreaders + fan built on (RAM) |
| Memory | 512mb PC-3200 DDR400 (set DDR-33 for o/c) by Corsair (matched pair, 2x256mb) 200.1/200mhz |
| Video Card(s) | BFG GeForce 7900 GTX OC 512mb GDDR3 ram (o/c manually to 686 core/865 memory) - PhaseChange cooled |
| Storage | Dual "Raptor X" 16mb 10krpm/RAID 0 Promise EX8350 x4 PCIe 128mb & Intel IO chip/CENATEK RocketDrive |
| Display(s) | SONY 19" Trinitron MultiScan 400ps 1600x1200 75hz refresh 32-bit color |
| Case | Antec Super-LanBoy (aluminum baby-tower w/ lower front & upper rear cooling exhaust fans) |
| Audio Device(s) | RealTek AC97 onboard mobo stereo sound (Altec Lansing ACS-45 speakers - 10 yrs. still running!) |
| Power Supply | Antec 500w ATX 2.0 "SmartPower" powersupply |
| Software | Windows Server 2003 SP #1 fully patched, & massively tuned/tweaked to-the-max (plus latest drivers) |
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
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