Can you post (here or on github) a sample of an actually created log?
Sure, here is a snippet of what you might expect on the header of a log:
18/02/2015 13:16:40.437, Driver, 4, \SystemRoot\System32\Drivers\crashdmp.sys
18/02/2015 13:16:40.453, Driver, 4, \SystemRoot\System32\Drivers\iaStor.sys
18/02/2015 13:16:40.453, Driver, 4, \SystemRoot\System32\Drivers\dumpfve.sys
18/02/2015 13:16:40.812, Driver, 4, \SystemRoot\system32\DRIVERS\cdrom.sys
18/02/2015 13:16:40.812, Driver, 4, \SystemRoot\System32\Drivers\Null.SYS
18/02/2015 13:16:40.828, Driver, 4, \SystemRoot\System32\Drivers\Beep.SYS
18/02/2015 13:16:40.843, Driver, 4, \SystemRoot\System32\drivers\watchdog.sys
18/02/2015 13:16:40.843, Driver, 4, \SystemRoot\System32\drivers\VIDEOPRT.SYS
18/02/2015 13:16:40.843, Driver, 4, \SystemRoot\System32\drivers\vga.sys
18/02/2015 13:16:40.843, Driver, 4, \SystemRoot\System32\DRIVERS\RDPCDD.sys
18/02/2015 13:16:40.859, Driver, 4, \SystemRoot\system32\drivers\rdpencdd.sys
18/02/2015 13:16:40.859, Driver, 4, \SystemRoot\system32\drivers\rdprefmp.sys
18/02/2015 13:16:40.859, Driver, 4, \SystemRoot\System32\Drivers\Msfs.SYS
18/02/2015 13:16:40.875, Driver, 4, \SystemRoot\System32\Drivers\Npfs.SYS
18/02/2015 13:16:40.875, Driver, 4, \SystemRoot\system32\DRIVERS\TDI.SYS
There is a separation between driver or process (module) to ease identifying what is what. I'm not so sure what the "4" and other numbers on the same field position are supposed to represent, just thought it might be useful to include the value but didn't had much time (or need) to check.
You can view/download a full log at https://github.com/n...15-13-17-11.log
I believe it will help in understanding what is logged and how and - indirectly - the tool may be useful/which added features it has when compared to - say - ntbtlog.txt and or a trace
From what I understand of ntbtlog.txt, its output is similar to:
Service Pack 1 8 10 2013 12:55:18.375
Loaded driver \SystemRoot\system32\ntkrnlpa.exe
Loaded driver \SystemRoot\system32\halmacpi.dll
Loaded driver \SystemRoot\system32\kdcom.dll
Loaded driver \SystemRoot\system32\mcupdate_GenuineIntel.dll
Loaded driver \SystemRoot\system32\PSHED.dll
Loaded driver \SystemRoot\system32\BOOTVID.dll
Loaded driver \SystemRoot\system32\CLFS.SYS
Loaded driver \SystemRoot\system32\CI.dll
Loaded driver \SystemRoot\system32\drivers\Wdf01000.sys
Loaded driver \SystemRoot\system32\drivers\WDFLDR.SYS
Loaded driver \SystemRoot\system32\drivers\ACPI.sys
Loaded driver \SystemRoot\system32\drivers\WMILIB.SYS
Loaded driver \SystemRoot\system32\drivers\msisadrv.sys
Loaded driver \SystemRoot\system32\drivers\pci.sys
Loaded driver \SystemRoot\system32\drivers\vdrvroot.sys
Loaded driver \SystemRoot\System32\drivers\partmgr.sys
Loaded driver \SystemRoot\system32\DRIVERS\compbatt.sys
From a first view I would say a point in favor of this boot logger (besides being open source) is that you get a time stamp when each driver is called. I could get a similar value using some sysinternals code but it is not permitted to be redistributed. A minus point for this custom boot logger is that I see some entries on the Windows tool that my driver is not capturing. For example: ntkrnlpa.exe, halmacpi.dll, ...
My goal here is to measure (more or less) accurately what is causing delays, so missing the early drivers doesn't bother me much since I'm more interested on seeing the performance of non-critical services and drivers usually loading later (printers, network drivers, ... ).
Also, it seems that nbtlog.txt includes some driver entries with no identification, meaning that they are launched but there is no name to be listed on the text file. On BootLogger this shouldn't happen.
A possible improvement in the future by someone knowledgeable on driver architecture could be adding this driver running at an a earlier point of the boot phase. Any volunteers?