Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Upcoming OSR Seminars | ||
---|---|---|
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
Kernel Debugging | 9-13 Sept 2024 | Live, Online |
Developing Minifilters | 15-19 July 2024 | Live, Online |
Internals & Software Drivers | 11-15 Mar 2024 | Live, Online |
Writing WDF Drivers | 20-24 May 2024 | Live, Online |
Comments
> I'm writing WDM driver...
Why? There are very, very few good reasons for writing a WDM driver
today. KMDF is unarguably better, and it handles the message-based
stuff for you.
> RtlZeroMemory( &IntParams, sizeof( IO_CONNECT_INTERRUPT_PARAMETERS ) );
>
> IntParams.Version = CONNECT_MESSAGE_BASED;
> IntParams.MessageBased.ConnectionContext.Generic = &DevExt->InterruptConnectionContext;
> IntParams.MessageBased.PhysicalDeviceObject = DevExt->PhysicalDeviceObject;
> IntParams.MessageBased.MessageServiceRoutine = Card_MessageSignaledISR;
> IntParams.MessageBased.ServiceContext = DeviceObject;
> IntParams.MessageBased.SpinLock = NULL;
> IntParams.MessageBased.SynchronizeIrql = 0;
> IntParams.MessageBased.FloatingSave = FALSE;
> IntParams.MessageBased.FallBackServiceRoutine = Card_InterruptServiceRoutine;
>
> Status = IoConnectInterruptEx( &IntParams );
What is the value of IntParams.Version when you return? Are you getting
a CmResourceTypeInterrupt in your AllocatedResourcesTranslated structure?
--
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
Tim Roberts, [email protected]
Software Wizard Emeritus
I finally managed to solve my problem so I'll share it here and perhaps someone will find it useful.
The value of IntParams.Version was CONNECT_MESSAGE_BASED after return and I was getting a CmResourceTypeInterrupt so that wasn't the problem. I also checked MessageAddress and MessageData fields from IO_INTERRUPT_MESSAGE_INFO_ENTRY and those values seemed valid.
Device Manager also showed in Resources tab that my driver has negative IRQ which indicates MSI...
But then I used !devext command in debugger and it said something like:
"Interrupt requirement: 1, Type - MSI
Interrupt resources: <none>"
and that was strange. Turns out I forgot to pass the IRP in StartDevice to a lower level driver and wait for it to complete and then return STATUS_MORE_PROCESSING_REQUIRED. After I did that my driver started working.
Thanks for answering Tim.
driver in WDM. KMDF takes care of this level of detail for you. Your
argument of learning Windows drivers in depth is invalid.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of [email protected]
Sent: Wednesday, April 26, 2017 5:23 PM
To: Windows System Software Devs Interest List <[email protected]>
Subject: RE:[ntdev] Missing MSI interrupts
The reason is that I wanted to learn in depth about Windows drivers.
I finally managed to solve my problem so I'll share it here and perhaps
someone will find it useful.
The value of IntParams.Version was CONNECT_MESSAGE_BASED after return and I
was getting a CmResourceTypeInterrupt so that wasn't the problem. I also
checked MessageAddress and MessageData fields from
IO_INTERRUPT_MESSAGE_INFO_ENTRY and those values seemed valid.
Device Manager also showed in Resources tab that my driver has negative IRQ
which indicates MSI...
But then I used !devext command in debugger and it said something like:
"Interrupt requirement: 1, Type - MSI
Interrupt resources: <none>"
and that was strange. Turns out I forgot to pass the IRP in StartDevice to a
lower level driver and wait for it to complete and then return
STATUS_MORE_PROCESSING_REQUIRED. After I did that my driver started working.
Thanks for answering Tim.
---
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://www.osr.com/seminars>
To unsubscribe, visit the List Server section of OSR Online at
<http://www.osronline.com/page.cfm?name=ListServer>
Your "fix" is exactly the reason no sane person would write a hardware driver in WDM. KMDF takes care of this level of detail for you. Your argument of learning Windows drivers in depth is invalid.
</quote>
Actually, it reminds me of a classical Russian XVIII -century comedy where the main character
questions the need for learning the geography - according to him, there is no need for it because cab drivers are going to take you to the target destination anyway, and, hence,learning the geography is not the right thing for a nobleman.....
Anton Bassov
> Actually, it reminds me of a classical Russian XVIII -century comedy where the
>main character
>questions the need for learning the geography - according to him, there is no
>need for it because cab drivers are going to take you to the target destination
>anyway,
But as it appears today, that was kinda prophesy. Russians can claim they invented self-navigating vehicles long before Google. And smart ovens too
Wait a little and Visual Studio will code for you...
-- pa