Reporting bugs
Table of Contents
While the author of UltraDefrag Driver has taken great pains to ensure that UltraDefrag operates properly, no software is perfect. As such bugs are inevitable. The author accepts bug reports and will attempt to fix issues that are brought to his attention. In order to facilitate this the author has built logging mechanisms into UltraDefrag. This document describes how to get these logs and attach them to your bug report.
Please report all problems and bugs via the bug tracker. Don't forget to register on sourceforge.net before. As an alternative you can send your report directly to the authors by email.
There are two possible types of kernel mode driver bugs:
NOTE: Ensure that your hardware is working properly! Faulty RAM or overclocked CPU may be a cause of the Blue Screen! Try one of the many free programs available for testing hardware (e.g. Memtest86+).
Algorithmic errors usually expresses themselves in file moving failures and other lightweight mistakes during the defragmentation process.
Let us assume that something goes wrong in defragmentation process, but Windows still works. Par example, you have noticed that some files are still fragmented after a job completion though they were not excluded by filters. How to understand what happens?
The best way to do so is running DbgPrint logger tool at the same time when you are defragmenting volume. This tool will collect debugging messages from our driver and will display them on the screen.
There are two popular DbgPrint loggers available. Both have freeware status, you may download them for free:
Note that you cannot use both loggers at the same time, otherwise debugging information may be partially losed.
First of all, if you are using Windows NT 4.0, you must download one of the earlier versions of DbgView that supports it. You may download the 4.05 version here.
DbgView is a nice graphical application which has very easy to use design. Run it and select item in menu. If you wish to debug the UltraDefrag boot time (native) interface, check also menu item. Now you can see all debugging information in application's window. Yes, it is empty at this moment, because UltraDefrag is still not running. To reclaim this mistake launch it and see something like this:
=Ultradfg= UltraDefrag v3.2.0
=Ultradfg= NT 5.1 free.
=Ultradfg= Kernel found: \WINDOWS\system32\ntoskrnl.exe
=Ultradfg= Kernel address: 804D4000
=Ultradfg= ExFreePoolWithTag address: 8053C789
=Ultradfg= KeDeregisterBugCheckReasonCallback address: 80525BD3
=Ultradfg= KeRegisterBugCheckReasonCallback address: 80506077
=Ultradfg= MmMapLockedPagesSpecifyCache address: 804ED02A
=Ultradfg= KeQueryInterruptTime address: 804EE0EA
=Ultradfg= Main FDO 81D055A0, DevExt=81D05658
=Ultradfg= Map FDO 81C1B8C8, DevExt=81C1B980
=Ultradfg= Stat FDO 81C29250, DevExt=81C29308
=Ultradfg= DriverEntry successfully completed
-Ultradfg- CreateFile request for main device
-Ultradfg- IOCTL_SET_USER_MODE_BUFFER
-Ultradfg- Address = 0047E060
-Ultradfg- IOCTL_SET_CLUSTER_MAP_SIZE
-Ultradfg- Map size = 910
-Ultradfg- Cluster map will be allocated from NonPagedPool.
-Ultradfg- IOCTL_SET_DBGPRINT_LEVEL
-Ultradfg- dbg_level=2
-Ultradfg- IOCTL_SET_SIZELIMIT
-Ultradfg- Sizelimit = 26214400
-Ultradfg- IOCTL_SET_REPORT_STATE
-Ultradfg- Disable reports: NO
-Ultradfg- IOCTL_SET_XXX_FILTER
-Ultradfg- Include: win
-Ultradfg- Filter strings:
-Ultradfg- + win
-Ultradfg- IOCTL_SET_XXX_FILTER
-Ultradfg- Exclude: config
-Ultradfg- Filter strings:
-Ultradfg- - config
As you can see, our driver successfully retrieved the Windows version and kernel entry points for some functions missing on NT 4.0. Also defragmentation options were successfully set.
If you will click button in UltraDefrag GUI you will see debugging information related to the volume analysis process. In case of running disk defragmentation job you will see detailed information about files moving including messages about possible moving errors.
When you close the Ultra Defragmenter you will see something like this:
-Ultradfg- STOP request
-Ultradfg- CloseHandle request for main device
-Ultradfg- In Unload Routine
-Ultradfg- Symbolic links were deleted
-Ultradfg- Deleted device 81B44500
-Ultradfg- Deleted device 81C29250
-Ultradfg- Deleted device 81C1B8C8
-Ultradfg- Deleted device 81D055A0
Here our driver reports you that it was successfully unloaded.
As you can see, debugging process is very easy. Enjoy it and don't forget to attach important parts of debugging log when you are sending a bug report.
Though DbgPrint Logger has no graphical interface it is still very easy to use. Click on DbgPrintLog.exe icon to run it. To close debugging session press Esc button. After that you will find debugging messages in DbgPrintXX.log file. Unfortunately text saved there has UNIX format. You can read them using standard Wordpad application included in all versions of Windows.
A little bit more hacking is needed for boot time logging. Save the following contents in udefrag-boot-logging.cmd file:
DbgPrintLog.exe --full -T DTN -wd c:\ --drv:inst 1 --svc:inst
A --drv:opt DoNotPassMessagesDown 1 udefrag.log
Note: write this instruction on a single line, without line breaks!
Click udefrag-boot-logging.cmd icon. Now DbgPrint Logger is ready to collect debugging information during Windows boot process. You will fing log files in root directory of volume C: as specified in DbgPrintLog.exe command options.
DbgPrint Logger can be executed on a large number versions of Windows, enjoy it and don't forget to attach important parts of debugging log when you are sending a bug report.
Download and install the following software to collect an additional information about running UltraDefrag components:
Fatal driver errors usually crashes your system.
When Windows dies, all running programs becomes died too. Therefore you cannot use DbgPrint logger at this time. Hopefully Windows itself contains one good mechanism that helps us to debug such kind of errors. Its name is Crash Memory Dump.
If something in driver goes wrong and Windows decides that this wrong behavior can damage your system, it stops any running processes and shows you BSOD screen with brief description of the encountered problem. It is a very good practice to have always a small piece of paper and a pencil near your machine. When you are encountering BSOD, write on paper numbers shown on your screen. To be able to attach these numbers to your bug report.
Note that BSOD showing feature itself is disabled by default in Windows. You should enable them manually by setting the following system registry value to 0x0 state:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\CrashControl\AutoReboot
What's about Crash Dump files? These files contain additional information about encountered problem. Therefore it will be very appreciated if you will attach the Crash Dump file to your bug report. It will help us to fix driver bug faster and easier.
Crash Dump generation may be disabled in your version of Windows. Therefore check please is it enabled or not by opening the following system dialog: .
It is highly recommended to select option in section of this dialog. Selecting kernel memory dump gives you an ability to get much more detailed information about a possible driver's failure. Usually such kind of memory dump requires few tens of megabytes of disk free space. If and only if you cannot provide such amount of disk space then select the option.
Note also: when you are selecting or options, you will always have after a crash a Small Memory Dump generated too.
The following set of screenshots illustrates crash dump tuning process.
Small Memory Dump files can be found in WINDOWS\Minidump directory. Kernel Memory Dump usually contains in a single WINDOWS\MEMORY.DMP file.
After setting crash dump parameters you are ready for basic driver testing. The process is very easy:
So, if you have encountered the Blue Screen, don't forget to attach a Small Memory Dump file to your report. Or, at least, attach please numbers shown on your screen. Sending debugging messages saved by DbgView program is very appreciated too.
There is one cool program shipped with all versions of Windows: Driver Verifier. Open the run box or command line and type verifier.exe to run it. As a result you will see its window. Select item and click button. Choose item and click again. Click button and select ultradfg.sys driver. Click button and reboot your system. Now you are ready for advanced UltraDefrag driver testing.
Play with UltraDefrag program trying to reproduce the Blue Screen. After arriving them send bug report with a small memory dump (and DbgView log) attached. And don't forget to attach a notice that you have used Driver Verifier during your test. Good luck!
The following set of screenshots illustrates a typical verifier's working session.
Use DbgView program or DbgPrint Logger as described above to understand better what happens when something goes wrong in the defragmentation process. Just don't forget to check the item in menu of DbgView program before.
Note also that unfortunately both described DbgPrint loggers cannot capture debugging output of the user mode driver at boot time which makes its debugging much more complicated.
Additionally keep in mind that user mode driver usually cannot cause BSOD. We know only a single exception for this rule - when you are trying to analyze/defragment NTFS formatted volume under NT4.0 anything may happen.
