No the answer is understand the Windows model, and use that. Just because Linux does something, does not mean Windows should. Having ported a large number of drivers from Linux to Windows, try to emulate the Linux behavior is a great way to produce garbage. The general rule if you are porting a driver should be take the key concepts (if it is hardware the key operations, if it is software the key algorithms), but throw away the interface, if you don’t it will be like one customer who insisted we match the Linux interface, we got 100K operations a second. We finally convinced them to let us use a Windows interface and we got to 600+K operations per second.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Marion Bond
Sent: Monday, May 05, 2014 7:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: [ntdev] How to shoot a process from kernel driver
This is all rather harsh for an OP who tells us that he is porting a broken by design interface from Linux to Windows. He is not using Windows terminology, but his intent is clear: there are concepts in my interface that do not correspond to concepts in Linux or Windows IO models, so what do I do when there are protocol violations in my interface model that aren’t detected by the OS? In Linux, the answer was terminate the process with a memory dump. In Windows, the answer is likely the same, but the mechanism is different. In Windows, the best way to do this is to suspend all threads of the process in question, inject a new one and have it raise an untangled exception. This will invoke the default handler - it used to be called Dr. Watson, but I have no idea what it might be called now - and will generate a memory dump
Sent from Surface Pro
From: xxxxx@flounder.com
Sent: Monday, May 05, 2014 5:58 PM
To: Windows System Software Devs Interest List mailto:xxxxx
The reasons for not doing this are technical. The moral decision is whether or not to risk the inevitable technical failures that will follow, and weighing the risks of these consequences against the consequences of not killing the threAd or pro ess.
As far as leaving a lock set that will deadlock the app…well, the app is buggy anyway. Screw it. And note that terminating a process has the same effect on other processes. And what sort of fool would set a lock and do a blocking or non-blocking I/O operation inside the lock? This already would be less than Best Practice. You can, if you are careful, get away with this; it happens a lot in the kernel. Observe the use of the word “careful” in that sentence.
The “terminate” call of operations has very simple behavior: it places a block of C4 in the control block and rubs like hell. When the C4 detonates, bits fly everywhere. And that’s the end of the thread or process. No DLL_THREAD_DETACH notifications. No DLL_PROCESS_DETACH notifications. No OnExit chains. Buffers which have not been flushed are lost. Pending. IRPs are. cancelled. How is this better than leaving a buggy process still running?
Did you ever read the “fine print” when you try to terminate a process via Task Manager? The part a out “may cause system instability”? THAT’S the technical reason. The rest is just deciding to avoid technical disasters by not engaging in activities that can cause them.
The reason many of us say “I would not do that” is because we know the potential consequences; the ones who say “I do that all the time, and it always works” are really saying “I do that all the time, but either have 't experienced the failure modes, or I’ve ignored them” and they rarely mean “I have been extremely careful to guarantee that Bad Things Cannot Possibly Happen”. And what that usually translates is “For the N possible things that could go wrong. I am aware of, and provided for the N - k things I am aware of”. As k approaches N, things get much dicier.
Joe
> On 05/05/2014 09:58 PM, Tracy Camp wrote:
>
>> I always find it a bit irritating when various folks claim something
>> can’t or shouldn’t be done simply because they wouldn’t themselves do
>> such a thing. Try and separate the moral viewpoint from the
>> technical viewpoint…
>
> Done.
>
>> Anyways, I think you might find that obtaining a handle to the
>> process object will enable you to call ZwTerminateProcess(). Pay
>> careful attention to the MSDN notes for the API about using a kernel
>> handle if you are going to do this.
>
> What I learn here is that there is no easy way, so I tend to simply
> not do it. Being blown off my stack does not sound like being easy.
>
> Thanks for the advice,
> Joerg
>
>>
>> t.
>>
>>
>> On Mon, May 5, 2014 at 12:53 PM, Jörg Faschingbauer
>> > wrote:
>>
>> On 05/05/2014 09:12 PM, Don Burn wrote:
>>
>> > There is no safe way to terminate a process from a driver, and
>> this should
>> > be avoided. Why would you want to kill the process, instead of
>> just
>> > rejecting the request?
>>
>> This is a valid option, no doubt.
>>
>> “Workflow ownership” violation, as it happens with their user/kernel
>> interface, is an application bug. Killing has the advantage (in
>> Linux)
>> that I can load the resulting core dump into the debugger and
>> immediately see what went wrong. Anyhow, if there is no safe way,
>> then
>> … well … I don’t mind so much.
>>
>> Can you give me pointers () where I can read up on why there’s
>> no safe
>> way? The project will keep me busy for some more time, and I feel
>> better
>> when I understand things.
>>
>> > Also, you state the driver will always be the top driver in the
>> stack, why
>> > do you think that? Also, that the request always comes from user
>> mode.
>> > While these are both likely conditions they certainly cannot be
>> guaranteed,
>> > and if this is important to you, you should be checking the
>> requestor’s
>> > mode.
>>
>> Later on, I’ll have to DMA into user allocated memory. As I
>> understand
>> this is only possible in a top level driver. Is this correct?
>>
>> () Is there a “The Book on Driver Programming”? I’ve read Helen
>> Custer’s “Inside Windows NT” ages ago. I see there’s “Inside Windows
>> 2000” (3rd Edition I believe), but that one is rather old too.
>>
>> Thank you,
>> Joerg
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> — NTDEV is sponsored by OSR Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>> http://www.osr.com/careers For our schedule of WDF, WDM, debugging
>> and other seminars visit: http://www.osr.com/seminars To unsubscribe,
>> visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx>