I have a PCI driver for a FPGA card that installs and works fine.However, we have a need to clean up our system without rebooting which includes unloading this driver.
When starting again (without rebooting) the driver is re-installed. I have found that when I do this process (install/uninstall) multiple times, on the 5th unload of the driver the directory associated with the device just disappears.
lspci command can no longer find my device because of a bad link. I have to reboot to get the device directory (/sys/bus/pci/devices/00000:04:00.0) to show up again.
With some experimentation and reducing the driver down to the bare minimum I discovered that if I do not do a call to pci_enable_device(..) function in my pci_probe_method, then I am able to install/uninstall the driver multiple times without error.
Of course, I need to call this method before I can do anything with the device but I wanted to be sure it was not some other of the more complex initialization I am doing was causing the problem.
I have verified that my call to pci_disable_device() is being called in the pci_remove_method(). I should be able to enable and disable a PCI device indefinitely, right? Any help in figuring out what is happening would be appreciated.
The actual solution to this problem was to eliminate an extraneous call I had to pci_dev_put(..). I did not notice this before when submitting the question. This was leftover from when this driver was not using the pci_probe() method to discover this device. So, executing this call in the exit routine caused the structure for this device to go away after 5 calls. So for now this problem is solved.
I made a device driver. But my system crashed at the moment when it was deleting the device object. I think the symbolic link was deleted and it crashed after it was trying to delete the device as I can't see the symbolic link in the Global.
How do I delete this device now. It also gives me a error popup(system cannot find the file specified Device\Mydriver) when I try to open the listed Mydriver under devices from Winobj.
I tried starting the driver's service again. I do get a handle back when opening the service. But it wont start now. giving the error value of Cannot find the file specified. I was working fine, i mean starting the driver before this crash.
I am a beginner with drivers and doing this to learn, please guide.
I have taken this from : Programming microsoft windows driver 2nd edition by woney
I hope this helps.
Removability of devices in a Plug and Play environment is the ultimate source of the early-unload problem
mentioned in the text. it’s your responsibility to avoid sending an IRP to a driver that might no longer be in memory
and to prevent the PnP manager from unloading a driver that’s still processing an IRP you’ve sent to that driver.
One aspect of how you fulfill that responsibility is shown in the text: take an extra reference to the file object
returned by IoGetDeviceObjectPointer around the call to IoCallDriver. In most drivers, you’ll probably need the
extra reference only when you’re sending an asynchronous IRP. In that case, the code that ordinarily
dereferences the file object is likely to be in some other part of your driver that runs asynchronously with the
call to IoCallDriver—say, in the completion routine you’re obliged to install for an asynchronous IRP. If you send
a synchronous IRP, you’re much more likely to code your driver in such a way that you don’t dereference the file
object until the IRP completes.
Use the interactive boot option and don't load the troublesome driver. Then you can experiment perhaps by adding diagnostic instrumentation to the driver or other debugging techniques to determine the underlying problem.
I have I/O Kit driver: virtual ethernet device. After some period of work OS hangs, so looks like I have some deadlock in my driver.
I've done next steps:
- connect two macbooks via FireWire
- set up debugging environment
- initialise NMI (via power button)
- connect to the target via gdb
- grab address of my kext
- create and load symbols (this is the last point in all docs I've read)
So far so good. In case of kernel panic it would be enough. But in my case there is no kernel panic and I reside in the thread that handle the NMI.
Now the question: how can I switch to the thread of my kext?
Command showalltasks gives me listing of all tasks, the only task where my kext may be running is kernel_task, so I'm trying to examine this task via showtaskthreads and showtaskstacks but can't find anything similar to my code. Am I missing something?
I would be appreciated for any suggestions or links to the docs.
I'm not answering your question directly - but would it be possible to hit your kext code with a breakpoint? A common method of kernel debugging is to nmi the machine, attach the debugger, put a breakpoint in the code of interest, resume execution (continue) and then do whatever is needed to hit the breakpoint.
Well, I'm answering my own question.
To see the thread using code of my kext I need to switch to the process using my kext. In my case it will be probably a browser (since my kext is the NKE).
But in fact it didn't help me a lot. But old print method helped me to find the deadlock. So my advice is next: for the kernel panic - use debugger, for the deadlock - use printing, find place where lock is and analyse code.
im writing a driver and I have a problem
everytime I try to open a handle to my driver using CreateFile, I get bsod (Access Violation)
It's important to mention that my driver loads successfuly and I dont get any errors
does someone knows how to handle it ?
Thanks in advance!
!analyze -v is your friend.
Turn on creating Kernel Dump in Windows settings and then analyze dump in WinDbg.
Are you using ZwCreateFile or Createfile? You can't use CreateFile in a driver because that is a usermode function and drivers run in kernel mode. Instead call ZwCreateFile which is the kernel mode version of CreateFile.
Another possible fault source: the driver-internal function for handling IRP_MJ_CREATE is either incorrectly assigned or faulty.
But you can only guess without analyzing the dump (maybe in conjunction with the symbols database of your driver [the PDB files]).
Just curious here: is it possible to invoke a Windows Blue Screen of Death using .net managed code under Windows XP/Vista? And if it is possible, what could the example code be?
Just for the record, this is not for any malicious purpose, I am just wondering what kind of code it would take to actually kill the operating system as specified.
The keyboard thing is probably a good option, but if you need to do it by code, continue reading...
You don't really need anything to barf, per se, all you need to do is find the KeBugCheck(Ex) function and invoke that.
http://msdn.microsoft.com/en-us/library/ms801640.aspx
http://msdn.microsoft.com/en-us/library/ms801645.aspx
For manually initiated crashes, you want to used 0xE2 (MANUALLY_INITIATED_CRASH) or 0xDEADDEAD (MANUALLY_INITIATED_CRASH1) as the bug check code. They are reserved explicitly for that use.
However, finding the function may prove to be a bit tricky. The Windows DDK may help (check Ntddk.h) - I don't have it available at the moment, and I can't seem to find decisive info right now - I think it's in ntoskrnl.exe or ntkrnlpa.exe, but I'm not sure, and don't currently have the tools to verify it.
You might find it easier to just write a simple C++ app or something that calls the function, and then just running that.
Mind you, I'm assuming that Windows doesn't block you from accessing the function from user-space (.NET might have some special provisions). I have not tested it myself.
I do not know if it really works and I am sure you need Admin rights, but you could set the CrashOnCtrlScroll Registry Key and then use a SendKeys to send CTRL+Scroll Lock+Scroll Lock.
But I believe that this HAS to come from the Keyboard Driver, so I guess a simple SendKeys is not good enough and you would either need to somehow hook into the Keyboard Driver (sounds really messy) or check of that CrashDump has an API that can be called with P/Invoke.
http://support.microsoft.com/kb/244139
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
Name: CrashOnCtrlScroll
Data Type: REG_DWORD
Value: 1
Restart
I would have to say no. You'd have to p/invoke and interact with a driver or other code that lives in kernel space. .NET code lives far removed from this area, although there has been some talk about managed drivers in future versions of Windows. Just wait a few more years and you can crash away just like our unmanaged friends.
As far as I know a real BSOD requires failure in kernel mode code. Vista still has BSOD's but they're less frequent because the new driver model has less drivers in kernel mode. Any user-mode failures will just result in your application being killed.
You can't run managed code in kernel mode. So if you want to BSOD you need to use PInvoke. But even this is quite difficult. You need to do some really fancy PInvokes to get something in kernel mode to barf.
But among the thousands of SO users there is probably someone who has done this :-)
You could use OSR Online's tool that triggers a kernel crash. I've never tried it myself but I imagine you could just run it via the standard .net Process class:
http://www.osronline.com/article.cfm?article=153
I once managed to generate a BSOD on Windows XP using System.Net.Sockets in .NET 1.1 irresponsibly. I could repeat it fairly regularly, but unfortunately that was a couple of years ago and I don't remember exactly how I triggered it, or have the source code around anymore.
Try live videoinput using directshow in directx8 or directx9, most of the calls go to kernel mode video drivers. I succeded in lots of blue screens when running a callback procedure from live videocaptureing source, particulary if your callback takes a long time, can halt the entire Kernel driver.
It's possible for managed code to cause a bugcheck when it has access to faulty kernel drivers. However, it would be the kernel driver that directly causes the BSOD (for example, uffe's DirectShow BSODs, Terence Lewis's socket BSODs, or BSODs seen when using BitTorrent with certain network adapters).
Direct user-mode access to privileged low-level resources may cause a bugcheck (for example, scribbling on Device\PhysicalMemory, if it doesn't corrupt your hard disk first; Vista doesn't allow user-mode access to physical memory).
If you just want a dump file, Mendelt's suggestion of using WinDbg is a much better idea than exploiting a bug in a kernel driver. Unfortunately, the .dump command is not supported for local kernel debugging, so you would need a second PC connected over serial or 1394, or a VM connected over a virtual serial port. LiveKd may be a single-PC option, if you don't need the state of the memory dump to be completely self-consistent.
This one doesn't need any kernel-mode drivers, just a SeDebugPrivilege. You can set your process critical by NtSetInformationProcess, or RtlSetProcessIsCritical and just kill your process. You will see same bugcheck code as you kill csrss.exe, because you set same "critical" flag on your process.
Unfortunately, I know how to do this as a .NET service on our server was causing a blue screen. (Note: Windows Server 2008 R2, not XP/Vista).
I could hardly believe a .NET program was the culprit, but it was. Furthermore, I've just replicated the BSOD in a virtual machine.
The offending code, causes a 0x00000f4:
string name = string.Empty; // This is the cause of the problem, should check for IsNullOrWhiteSpace
foreach (Process process in Process.GetProcesses().Where(p => p.ProcessName.StartsWith(name, StringComparison.OrdinalIgnoreCase)))
{
Check.Logging.Write("FindAndKillProcess THIS SHOULD BLUE SCREEN " + process.ProcessName);
process.Kill();
r = true;
}
If anyone's wondering why I'd want to replicate the blue screen, it's nothing malicious. I've modified our logging class to take an argument telling it to write direct to disk as the actions prior to the BSOD weren't appearing in the log despite .Flush() being called. I replicated the server crash to test the logging change. The VM duly crashed but the logging worked.
EDIT: Killing csrss.exe appears to be what causes the blue screen. As per comments, this is likely happening in kernel code.
I found that if you run taskkill /F /IM svchost.exe as an Administrator, it tries to kill just about every service host at once.