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.
Is there any bottleneck above the physical the cpu and HAL? Or are there multiple ways a process could start under Windows XP, Vista, or 7, that don't invovle CreateProcess at some point?
Given the comment on your question:
Building an Anti-Executable driver, just planning, wondering if controlling createprocess would be enough.
No it wouldn't be enough if security is your concern. There is NtCreateProcess below that one for example. And those aren't the only ones.
The best way provided by the system is a file system filter driver. In fact the WDK comes with samples that require only a moderate amount of change to do what you're asking. Since you asked about XP you can use a minifilter if you can get away with support for XP SP1 and later.
PsSetLoadImageNotifyRoutine and PsSetCreateProcessNotifyRoutine are unfortunately only notifications. So they don't allow to do anything about the event that they notify about. And you really shouldn't attempt to work around this.
In the old times I have seen some clever implementations using SSDT hooks on ZwCreateSection that would exchange the returned handle with one to an executable that shows an error message. Since the executable itself sees the original command line, it can then show a nice error message informing the user that the command has been banned for reasons xyz. However, with Vista and later and even on XP and 2003 64bit (x64), it's going to be harder to write the SSDT hooks. Not to mention that everyone would frown upon it, that it requires quite extensive experience to get it right (and even then it often has flaws that can cause havoc) and that you can forget any certifications you may be aspiring for in the Windows Logo process.
Conclusion: use a file system filter driver to deny access to unwanted executables. With a minifilter the learning curve will be moderate, with a legacy filter I'll recommend you take a few courses first and then start your first attempts.
Looking through a quick disassembly of CreateProcess, it appears that the two main things it does are:
Call NtCreateUserProcess (this is syscall 0xAA) to actually create the process structures in the kernel (PEB, etc.)
Start the new process with a call to NtResumeThread (syscall 0x4F).
The Windows Internals books certainly detail this process very well.
I'm not sure if there are designated hooks in the kernel which would allow you to create your anti-executable driver. It used to be that you could hook the "System Service Dispatch Table" to change how these system calls behaved. But now, technologies like PatchGuard prevent a driver from doing this (and allowing the system to run).
When a volume is attached to file system, on Windows,
the Window explorer detects the volume and refreshes automatically.
I wonder the technique.
How do an program(include device driver) get the notification?
-Of course, it doesn’t mean a polling. I want to get an event(or a message).
I would like to get the notification when a network volume(like SMB) is attached.
Thanks in advance.
You're going to have to do some research, but basically you just need to register with the Windows IO Manager so that when the device is connected, some part of your code is called. RegisterDeviceNotification() is probably a good place to get started. When the device is connected, the IO Manager will send you a message, so you should make sure you have a proper callback setup for the message.
It would not hurt to read up on Windows Devices Services from the Windows System API. Depending on what you are doing, you may or may not need a driver as the generic driver provided by Microsoft is often good enough. For drivers, check out the Windows Driver Kit, it contains an excellent collection of sample drivers, as well as Win32 code for interfacing with drivers and working with hardware.
Good luck!
I want to know which threads processes device interrupts. What happens when there is a interrupt when a user mode thread is running? Also do other user threads get a chance to run when the system is processing an interrupt?
Kindly suggest me some reference material describing how interrupts are handled by windows.
Device interrupts themselves are (usually) processed by whatever thread had the CPU that took the interrupt, but in a ring 0 and at a different protection level. This limits some of the actions an interrupt handler can take, because most of the time the current thread will not be related to the thread that is waiting for the event to happen that the interrupt is indicating.
The kernel itself is closed source, and only documented through its internal API. That API is exposed to device driver authors, and described in the driver development kits.
Some resources to get you started:
Any edition of Microsoft Windows Internals by Solomon and Russinovich. The current seems to be the 4th edition, but even an old edition will help.
The Windows DDK, now renamed the WDK. Its documentation is available online too. Be sure to read the Kernel Mode Design Guide...
Sysinternals has tools and articles to probe at and explain the kernel's behavior. This used to be an independent site until Microsoft got tired of Mark Russinovich seeming to know more about how the kernel worked than they did. ;-)
Note that source code to many of the common device drivers are included in the DDK in the samples. Although the production versions are almost certainly different, reading the sample drivers can answer some questions even if you don't want to implement a driver yourself.
Like any other operating system, Windows processes interrupts in Kernel mode, with an elevated Interrupt Priority Level (I think they call them IRPL's, but I don't know what the "R" stands for). Any user thread or lower-level Kernel thread running on the same machine will be interrupted while the interrupt request is processed, and will be resumed when the ineterrupt processing is complete.
In order to learn more about device interrupts on Windows you need to study device driver development. This is a niche topic, I don't think you can find many useful resources in the Web and you may have to look for a book or a training course.
Anyway, Windows handle interrupts with Interrupt Request Levels (IRQLs) and Deferred procedure calls. An interrupt is handled in Kernel mode, which runs in higher priority than user mode. A proper interrupt handler needs to react very quickly. It only performs the absolutely necessary operations and registers a Deferred Procedure Call to run in the future. This will happen, when the system is in a Interrupt Request Level.
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.