When I want to enable ETW tracing to receive driver events, I do such:
logman start "NT Kernel Logger" -p "Windows Kernel Trace" (driver) -o s.etl -ets
So on some machine, after running the above command, the computer crashes. After analyzing the memory dump, I figured out that the problem was caused by "TAOKernel64.sys" which is developed by a Chinese company named "Tencent". After removing a program which installed that driver (QQ PC Manager), the problem resolves.
I had two major questions:
1-
Does receiving driver events from ETW require all drivers to work properly? So can we have a buggy driver installed and enabled (but not used) and use ETW without causing BSOD? Or I had faced a completely different problem?
2-
Can we filter out some of these drivers in ETW (either real-time or offline)? For example, telling ETW not to collect driver events from that .sys file?
Related
I'm remote-debugging a Windows kernel-mode driver using WinDbg. The driver has issues in the initialization routine, leading to a bugcheck/crash when installing the device driver. When I detach the debugger, the target PC reboots and runs again into the same bugcheck.
In order to test a new version of the driver, I therefore have to boot into safe mode, uninstall the device using device manager and reboot into normal mode.
Is there any way to simplify this workflow so that the device driver is automatically removed upon rebooting after a bugcheck?
Additional infos:
I'm using dpinst to install the driver on the target PC
use .Kdfiles to pull a replacement driver during boot
Documentation From MS
Write Up in Nt Insider From Osr Online
if you are using windows 10 then you can leverage the -m option to provide a partial name
and forego the dospath C:\ NtPath \.\xx , %SystemRoot%
confusions in the map file formats ,
or as described here
I need to monitor registry changes on windows machine. Is it possible to use RegistryCallback from a user mode windows service instead of from a windows driver? Most of the examples are used in a driver.
AFAIK no, because it is registered via CmRegisterCallback() and CmRegisterCallbackEx(), which are only callable in kernel-mode drivers.
User-mode processes can use RegNotifyChangeKeyValue(), but it does not report detailed information about any changes made to the Registry.
SysInternals Process Monitor uses a kernel-mode driver to monitor detailed Registry activity for display in a user-mode viewer.
I am new to Window driver development.
I am trying to understand the working of a NDIS miniport driver (from Microsoft WDK samples). Especially, to understand the packet flow.
As per numerous sources, I have seen suggestions of installing two instances of NDIS miniport driver and proceed from there. However, I am unable to continue from there, as there is only vague info. Please advise - Especially on how to attach a Windows Debugger Tool to an instance of the driver and to see the callbacks being called on sent/receive packets.
My platform: Windows 7 x64 with debug mode set (Debugging Setup: Single Computer).
There is a similar question. But no info about how to debug the driver: NDIS and miniport driver
You can't debug on the same machine in which you are running the driver, you need to use remote machine, that could be a "Real" one or as done usually a VirtualMachine.
Here how to setup a Windows Kernel Debugging environment with a Virtual Machine:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff538143%28v=vs.85%29.aspx
Best way to understand driver internals of driver is to use WPP tracing in driver to print messages and view using traceview.exe. Or using dbgprint() to print messages and these messages are viewed using dbgview.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff556204(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/ff543632(v=vs.85).aspx
I have to maintain a WDF driver. This is a no-hardware driver: the driver use a disk file which is mounted as a Windows partition. All the data written to the disk are encrypted by the driver. The driver run in kernel mode.
The driver has been developed on XP and successfully ported on Vista and 7, 32 & 64 bits. I encounter one big problem on Windows 8. The driver lead to a fatal system error:
BugCheck 50, {ffffffffffffffd0, 0, fffff800002de33a, 0}
Probably caused by : Wdf01000.sys ( Wdf01000!FxDevice::DispatchWithLock+fa )
The problem occurs after deleting the device with WdfObjectDelete(). As long as the device is not deleted the driver run fine and there is no system error. When WdfObjectDelete has been called, the system crashes after a certain delay.
verifier detects no error in the driver. My questions are the following:
Is there anything special regarding WDF on Windows 8?
Is there any tool/technique that could help me finding the bug in the driver?
There shouldn't be anything specific to Windows 8 for this issue. I'd recommend starting to debug your driver with WinDbg via a remote system. With this you can set breakpoints, step through the code and most importantly get post-mortem information on the crash. Once you have connected a machine, and you can see they crash use analyze -v to get information. OSR is a great resource for BSOD debugging.
I'm finding it difficult to see the debug output from a kernel-mode driver I'm working on.
I'm new to driver development. I'm trying to debug a USB driver on Windows XP. I've installed the DDK, and built a "checked mode" build of my driver. I've installed the driver and if I use a hex editor to look at my driver's .sys file in windows/drivers, I can see the text of my debug output strings.
If I run an app that uses my driver under Visual Studio, my debug output doesn't appear in the output window, as the application's own debug output does. Searching the web, I find many different claims about how one is supposed to display debug output from the kernel. For kernel debugging in general, people seem to either do remote debugging over a NULL modem cable (Crikey, it's 2012) or use a virtual machine and a virtual com port. Both these approaches seem like a massive amount of work just to be able to see debug output. Is there an alternative?
I've tried using WinDbg in "Local" kernel debugging mode but it doesn't show anything. It warned that I should reboot windows with "/debug" enabled. I did that, but it didn't help.
Any other ideas? Or am I asking for the impossible?
DebugView will show you the trace messages from your driver:
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx
However, you really do need a two machine setup to do any real development work.
The information you found is correct. You do need 2 machines to debug kernel-mode drivers.
If you choose to use 2 physical machines they can be connected via USB. NULL modem (COM port) is a common way to attach debugger to a virtual machine where VM's COM port is seen as a named pipe on the host, so you don't really need a NULL modem cable.
Couple of links
http://msdn.microsoft.com/en-us/library/ff538141.aspx
http://msdn.microsoft.com/en-us/library/ff542279.aspx