Anton,
From the documentation on KeLowerIrql I don’t believe I can lower the IRQL from DISPATCH_LEVEL to ACP_LEVEL but if I’m wrong, it would be an easy solution to my problem. So what’s the harm in asking those who actually know?
Randy
> So what’s the harm in asking those who actually know?
Well, there is no harm,of course, but this question reveals the level of your “understanding” of the environment you are trying to program in, as well as that of the internals of the OSes in general. Basically, your question is “I run in atomic context. Can I temporarily enable preemption so that I can make a blocking call”…
Certainly, I DO realize that our “usual suspects” are about to jump in and tell us that we were all inexperienced at some point, but still…
Anton Bassov
Randy Lewis wrote:
From the documentation on KeLowerIrql I don’t believe I can
lower the IRQL from DISPATCH_LEVEL to ACP_LEVEL but if I’m
wrong, it would be an easy solution to my problem.
Earlier, it was suggested to OP to learn the C programming language. Perhaps learning the English language would be a better first step.
I started monitoring the IRQL level at various points in my driver and found that it only changes from PASSIVE_LEVEL on entry to my FilterRequestCompletion callback function. However, it does not always change. Since the same request packet is being sent to the device every time (at least it is during my current testing) I don’t understand why the packet returned from the device would sometimes be at IRQL 0 and at other times be at IRQL 2. Is there something I can do within my driver to prevent this change or at least limit it to IRQL 1?
For those of you who feel obliged to make derogatory comments I admit I only started writing device drivers this year and there is A LOT I don’t know, but believe it or not I have accomplished a lot in spite of this, thanks in part to those who actually provide helpful feedback. But I’m thick skinned so feel free to make your immature comments if you must.
The IRQL your completion routine is called at depends on the IRQL of the driver that called IoCompleteRequest on the PIRP. the rules state that it must be IRQL <= DISPATCH_LEVEL, there is no rule about consistency. No, there is no to force it to a specific IRQL. If you are wondering why you are seeing different IRQLs for the same IO it probably has to do with the state of the underlying device. I would guess if there is data already available and queued up in hidclass, hidclass will complete the request immediate in the context in which you are initially sending the request. In the dispatch_level case, there is probably no underlying data queued up, so hidclass queues your request and completes it when data shows up from the device, which is probably indicated in a DPC from the underlying hardware bus.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, May 23, 2016 1:51 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Problem using EVENT object in KMDF filter driver
I started monitoring the IRQL level at various points in my driver and found that it only changes from PASSIVE_LEVEL on entry to my FilterRequestCompletion callback function. However, it does not always change. Since the same request packet is being sent to the device every time (at least it is during my current testing) I don’t understand why the packet returned from the device would sometimes be at IRQL 0 and at other times be at IRQL 2. Is there something I can do within my driver to prevent this change or at least limit it to IRQL 1?
For those of you who feel obliged to make derogatory comments I admit I only started writing device drivers this year and there is A LOT I don’t know, but believe it or not I have accomplished a lot in spite of this, thanks in part to those who actually provide helpful feedback. But I’m thick skinned so feel free to make your immature comments if you must.
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>
Doron,
Is there anything in a request packet from the user app (whose packets I am modifying in my driver) that would cause the IRQL to change? And if so can I modify the parameter responsible before passing the packet to the device?
Randy
No
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, May 23, 2016 2:24 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Problem using EVENT object in KMDF filter driver
Doron,
Is there anything in a request packet from the user app (whose packets I am modifying in my driver) that would cause the IRQL to change? And if so can I modify the parameter responsible before passing the packet to the device?
Randy
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>
Mr. Lewis, with all due respect you’re question amounts to “I don’t understand anything about the steering wheel or the clutch pedal… Please explain to me how to drive a car with a manual transmission.”
I’m sure you’ll think that reply unkind, but I’m not a big fan of somebody knowing just barely enough to make a driver sort of work writing code that runs in kernel-mode. Either properly learn how to,do what you’re doing, or leave the job to the people who do this sort of work for a living.
https:</https:>
Peter
OSR
@OSRDrivers
Peter,
I put a lot of effort into trying to figure things out on my own before asking questions (most of them anyway) but in case you’ve forgotten there is an incredible amount of driver development documentation to sort thru and unless one has an idea of what to be looking at most of it ends up not being applicable to the problem at hand. And there are so many different ways of doing the same thing its difficult to know which of them to pursue. And a lot of what is applicable is frequently not self explanatory without already knowing a lot about the background material. Endless hours of researching can be expended (and I have spent more than I could recount doing this) looking for enlightenment. I don’t believe it is possible for someone to learn to write useful drivers simply by reading the available documentation without first trying, failing, learning from mistakes and the wisdom of those who have gone down this path before. I choose to ask questions after a reasonable amount of research has not produced a satisfactory answer. I think this is the proper way to learn. And in regards to your vehicle analogy I am a Mechanical Engineer and could give you a lesson or two about how a vehicle operates. But I won’t hold it against you, being programmer rather than a mechanical engineer, if you try to learn about them and do some tinkering with your own vehicle. So why aren’t you willing to afford the same courtesy to me or non-professional programmers like me with regard to device driver programing?
Randy
On May 23, 2016, at 11:49 AM, xxxxx@gmail.com wrote:
From the documentation on KeLowerIrql I don’t believe I can lower the IRQL from DISPATCH_LEVEL to ACP_LEVEL but if I’m wrong, it would be an easy solution to my problem.
Here’s the reason. If you are at DISPATCH_LEVEL, you are there for a reason. Often, the reason is because you are holding a spin lock, The raised IRQL is used to prevent contention and deadlocks. Let’s say you lower your IRQL while you hold a spin lock. As SOON as you do that, your thread will be placed on hold and the next waiting DISPATCH_LEVEL thread will run in your place. If that thread happens to want your spin lock, you have a deadlock. The new thread can’t acquire the spin lock because you own it, and you won’t ever get a chance to run again because there is a higher IRQL thread running.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> I choose to ask questions after a reasonable amount of research has not produced
a satisfactory answer. I think this is the proper way to learn.
I dunno, but I would say that the proper way to learn things (not only driver writing) is to say “Guys,I don’t know anything about XYZ but I want to learn it. Which books and other sources of info would you recommend?” I can assure you that if you did it this way no one would be ironical about you. Get yourself a copy of “Windows Internals” and familiarise yourself with the basics that make the Windows kernel tick. This is not the kind of book that gives you a practical “Do ABC and XYZ guide” but it will give you a basic understanding of the system that you are trying to program.
I am a Mechanical Engineer
Now imagine some would-be “engineer” asking you questions on how to do things in your field, and these questions reveal that the guy is unfamiliar with either calculus or the basics of Newtonian mechanics. Furthermore, the way he treats your replies reveals his unwillingness to familizarise himself with concepts that are essential for Mechanical Engineering. What would you say here???
Anton Bassov
@Mr. Lewis: Did you NOT read the link I provided? Go read it. Please. It’ll explain my replies to you in this thread.
@everyone else:
OMG… I think I agree with something Anton posted.
Somebody, get me a glass of water…
Peter
OSR
@OSRDrivers
> OMG… I think I agree with something Anton posted.
Somebody, get me a glass of water…
What you need here is not a glass of water but quite a few pints of lager, stout or ale - you should go to the pub and celebrate your achievement. If you keep progressing at such pace, we may agree on something else probably even before Mr.VinayKP writes a bugfree production-grade NDIS driver…
Anton Bassov
this thread has gotten from sad to funny to sad and now it’s funny again.
My quick advice for the poster, and don’t take it the wrong way, but at the
moment, before going into any windows internals please take the time to go
through that documentation with a little more attention and practice a lot
with WinDbg. Get really comfortable with it. If you can afford, get the
Inside Windows Debugging from Microsoft press. Go through it and practice.
The fact that you tried to do this:
&event = 0xac1d3a50
event = 0x40000
in the begging of the thread with a pointer to an event shows you lack of
experience here and what would help you a lot is actually see these things
in the debugger and how they look. Actually make sure your C skills are
really good. All samples from Microsoft are written in C and most probably
you will do the same.
Secondly, you need to take the time and understand how windows works and
then your doubts about why you should not lower irqls etc… will become
clear, more so you will chose an architecture for your project that in the
end does not end-up in a dead-end like this.
The first steps would be to go through the Windows Internals books. After
you feel comfortable with those it would be necessary to start reading the
“Windows NT Device Driver Development” from the OSR Classic reprints ( one
of my favorites and the one I got in high school and started learning from)
and if you have a taste for file systems, you can add the Windows NT
Filesystem Internals in there. Find them here:
https://store.osr.com/product/osrs-classic-reprints-windows-nt-device-driver-development/
. They certainly helped me get going.
If you feel like Windows NT Device Driver Development is not the way to go
for you, maybe you could try “Programming the Microsoft Windows Driver
Model” by Walter Oney to get started on the basics of Windows driver
development.
Third, take the time to look at samples. Take the time to analyze them
debug them, run them and see how and why the work the way they work.This is
not a fast pace process, will take you probably years at this point to get
to a level where you could be comfortable starting your driver project and
chose a adequate architecture for it and post more relevant questions that
are not to do with the lack of knowledge of the basics but rather
unexpected scenarios or difficult debugging situations, deadlocks, leaks,
etc…
My last advice would be to actually listen, read and try to understand what
these people on this forum advise you, consult the archives, write less and
work more ( on your own ). People around here have even in the tens of
years of experience, and have heard these exact questions and doubts that
you’re having believe hundreds of times, so take a step back, educate
yourself more, listen, really listen to what more experience people have to
say, think about it and work hard. There are today exponentially more
places to find resources and documentation for this, but one thing remained
the same and that is, there are no shortcuts or gimmicky answer here nor
there is any room for impatience and lack of frustration and despair in
this field, so be ready for what is to come.
Regards,
Gabriel
www.kasardia.com
Windows Kernel Driver Consulting
On Tue, May 24, 2016 at 1:30 PM, wrote:
> @Mr. Lewis: Did you NOT read the link I provided? Go read it. Please.
> It’ll explain my replies to you in this thread.
>
> @everyone else:
>
> OMG… I think I agree with something Anton posted.
>
> Somebody, get me a glass of water…
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
>
–
Bercea. G.</http:>
Gabriel,
Thank you for the constructive comments. I’m sure that your “specific” references will prove enlightening.
But the point I’ve been trying to make is that asking questions is part of learning and demonstrates that the person asking either doesn’t know the answer or is perhaps seeking confirmation of what they may think the answer is. A person shouldn’t be afraid to ask (or be ridiculed for asking) questions. And a helpful answer to a question is usually not “go read the documentation”. I have read mountains of DDK documentation, Microsoft articles and forum postings. I own and have read “The Windows 2000 Device Driver Book”, “Programming the Microsoft Windows Driver Model” and “Developing Drivers with the Windows Driver Foundation”. I look forward to adding some of the references that you have recommended. I use WinDbg a lot but I’m sure your recommended reference “Inside Windows Debugging from Microsoft press” will be helpful. The bottom line, however, is that all (or at least most) of these references and articles are written by people who already know the material inside and out and they often aren’t effective at communicating to someone who is not so familiar with the material. I wouldn’t hand you a book on Physics and expect that you would be able to explain how an internal combustion engine works after reading it. You would need some coaching and guidance along the way and additional “specific” recommended references to read. And unless you asked questions I wouldn’t know what you needed help with.
And in regards to my C programming knowledge, the text in my original post:
&event = 0xac1d3a50
event = 0x40000
do not represent lines of code but rather show the results that were displayed using KdPrint to verify that &event did exist in memory and that there was data within it. The only lines of code given in the posting are:
KEVENT event;
KeInitializeEvent(&event, NotificationEvent, FALSE);
irp = IoBuildSynchronousFsdRequest(IRP_MJ_WRITE, DEVICE_OBJ, writeBuffer,
17, 0, &event, &iosb);
I don’t think you can accuse me of misusing the C programming knowledge based on these.
Bottom line is that constructive feedback, like what you and a number of others have provided on this posting, are helping me learn and succeed at achieving my end goal. Derogatory comments and feedback like “read the documentation”, “learn C programming” and “learn English” have contributed nothing.
IoBuildSynchronousFsdRequest is a WDM routine.
Are you working on a KMDF or WDM driver ?
How do you get called at that high IRQL ?
So you are an engineer (like me) who has found a problem in a foreign discipline you don?t understand. It is perhaps unkind for us all to question your understanding of the pertinent topics, but from a person competent in this field you are incompetent
To resolve this, you need to either read a lot more or take some training courses. You think that you have read a lot, but I can assure you that unless you are measuring your experience in decades, well take it ask you will
As Peter has pointed out on another thread some of us a arrogant and unrepentant ? but the fact that we are still employed should tell you something
As an aside, it is very easy for me to make arbitrarily candid posts as I do so from the cancer ward. If it is possible for you to believe, the only reason I wish to is that I want you to succeed. Otherwise I would direct my remaining energies else ware
Sent from Mailhttps: for Windows 10
From: xxxxx@gmail.commailto:xxxxx
Sent: May 24, 2016 11:08 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Problem using EVENT object in KMDF filter driver
Gabriel,
Thank you for the constructive comments. I’m sure that your “specific” references will prove enlightening.
But the point I’ve been trying to make is that asking questions is part of learning and demonstrates that the person asking either doesn’t know the answer or is perhaps seeking confirmation of what they may think the answer is. A person shouldn’t be afraid to ask (or be ridiculed for asking) questions. And a helpful answer to a question is usually not “go read the documentation”. I have read mountains of DDK documentation, Microsoft articles and forum postings. I own and have read “The Windows 2000 Device Driver Book”, “Programming the Microsoft Windows Driver Model” and “Developing Drivers with the Windows Driver Foundation”. I look forward to adding some of the references that you have recommended. I use WinDbg a lot but I’m sure your recommended reference “Inside Windows Debugging from Microsoft press” will be helpful. The bottom line, however, is that all (or at least most) of these references and articles are written by people who already know the material inside and out and they often aren’t effective at communicating to someone who is not so familiar with the material. I wouldn’t hand you a book on Physics and expect that you would be able to explain how an internal combustion engine works after reading it. You would need some coaching and guidance along the way and additional “specific” recommended references to read. And unless you asked questions I wouldn’t know what you needed help with.
And in regards to my C programming knowledge, the text in my original post:
&event = 0xac1d3a50
event = 0x40000
do not represent lines of code but rather show the results that were displayed using KdPrint to verify that &event did exist in memory and that there was data within it. The only lines of code given in the posting are:
KEVENT event;
KeInitializeEvent(&event, NotificationEvent, FALSE);
irp = IoBuildSynchronousFsdRequest(IRP_MJ_WRITE, DEVICE_OBJ, writeBuffer,
17, 0, &event, &iosb);
I don’t think you can accuse me of misusing the C programming knowledge based on these.
Bottom line is that constructive feedback, like what you and a number of others have provided on this posting, are helping me learn and succeed at achieving my end goal. Derogatory comments and feedback like “read the documentation”, “learn C programming” and “learn English” have contributed nothing.
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>
MM,
I was not going to post any further replies to this thread but given your circumstances and the fact that you expended the energy to provide a comment I feel obligated to do so.
First, thank you for your comments. I appreciate that you want to see me succeed and I certainly won’t argue about my inexperience in this field. The shear volume of documentation and seemingly endless choices in methods to achieve a given result make for a very steep learning curve. In spite of this I have come a long way over the last several months and have achieved significant success with getting my driver to do what I want. But then I go and decide to add another feature and run into some new roadblock that requires a deeper understanding of some aspect of interfacing with the OS. When this happens I do read the documentation that I can find but there is so much to sort thru (and so much that does not apply) and the online documents are nested so deeply that I easily get lost in short order. So rather than spending endless hours continuing to get nowhere I will post a question hoping someone will point me in the right direction to make my efforts worthwhile or give me a clue as to what I should be looking for. If the reply I get is “read such and such document or publication on the topic” or review “such and such sample driver” that would be great. But replies like “read the documentation” are not helpful at all. I don’t see the problem with my approach and don’t understand why some commenters get so bent out of shape about it.
Sincerely,
Randy
That’s why, if you’re not coming from a strong device-driver background (on another OS), or even if you are, the quickest way to find out what you need to know is to take a seminar that’s taught by somebody who’s been developing drivers for many years. 5 days is all you need to learn the fundamentals of KMDF (and Windows I/O Subsystem Architecture).
Peter
OSR
@OSRDrivers
Peter,
Thanks so much for this suggestion. Am I correct in thinking that OSR hosts
these periodically and aren’t there some that have been archived as online
documentation?
Randy
On Wed, May 25, 2016 at 3:03 PM, wrote:
>
>
> That’s why, if you’re not coming from a strong device-driver background
> (on another OS), or even if you are, the quickest way to find out what you
> need to know is to take a seminar that’s taught by somebody who’s been
> developing drivers for many years. 5 days is all you need to learn the
> fundamentals of KMDF (and Windows I/O Subsystem Architecture).
>
> Peter
> OSR
> @OSRDrivers
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>