DeviceSuggestions


If you would like me to write about a topic that relates to WDM, the kernel, debugging, WDF, KMDF, UMDF, or anything that I have refered to in other entries, please add a comment to this entry.  Comments will be cleared out periodically if there is enough traffic.


Comments (34)

  1. rodrigostrauss says:

    Debugging tricks, some KMDF basics, code quality and tools (WinDbg/kd, PREfast), maybe tips to debug/test using VirtualPC/VMWare.

  2. A bit about me:

    I grew up in the Bay Area and got my B.S in CSc from Cal Poly, SLO

    I have been working…

  3. diegocg says:

    I find weird that you can use only signed "themes" in XP. There’re utils out there that patch some .dll to make possible to use any theme.

    Why this? I often think that this is because the themes will be run in kernel mode and so only signed themes are allowed to run so you can’t build "malicious themes", that would make sense. Am I right?

  4. doronh says:

    I am a kernel guy, not a user guy so I can’t answer definitively, but I can take a good shot at the answer (and i would guess that raymond chen would know the answer definitively).  If a theme DLL is just normal DLL, it can’t be loaded in KM to begin with, the imports it would require are not there so I don’t think the DLL needs to be signed for that reason.  One way theming could be done is to have the theming DLL be injected into all processes.  If that were the case, you would want to make sure that the DLL you are placing in every process is not malicious.  

    With that said, I know there is a theming service which you can stop/start on the fly.  I don’t know if the DLL is only in that process or the DLL uses an IPC to talk to the service, but even if it is in the service and not in other processes, the service is also a trusted entity and you don’t want malicious code in there either.

  5. poltrone says:

    The size of a memory block that can be descibed by an MDL is limited by the WORD-sized field describing the size of the MDL itself. I wonder why the size field was not expanded (say to a DWORD) when the step was made to 64 bit environments.

  6. paulsli says:

    Poltrone, we’ve addressed this in Vista; the size field can wrap so there is no longer that limitation when calling IoAllocateMdl.  

    Also, hopefully you aren’t relying on the ‘internal’ size field of MDLs since it is documented as opaque 🙂

  7. doronh says:

    More info on the Size field.  I asked our memory manager dev and said:

    "The Size field is ignored (was never needed from the beginning).  

    The real governing field is the ULONG ByteCount (hence MDLs can only describe a range < 4gb in length)."  

    I’ll ask Paul for more info tomorrow 😉

  8. MSDNArchive says:

    I would LOVE a tutorial, kinda like Raymond Chen’s multipart blog entries.  Start by giving us the basics of device drivers and implementations, then lead us through writing a basic device driver.

  9. poltrone says:

    Sure i’m not relying on opaque structrure internals 😉

    But i always thougt that it was the limitation of Size field which lead to the documentation of IoAllocateMdl where it says:

    <quote>

    Length

    Specifies the length in bytes of the buffer the MDL is to describe. This value must be less than PAGE_SIZE * (65535 – sizeof(MDL)) / sizeof(ULONG_PTR).

    </quote>

  10. doronh says:

    Nevo:  that’s in the plans, I just have a lot of topics to lay some groundwork down first ;).

  11. hanzhu says:

    Could you provide us some kernel debug tips, KMDF internal information, and some other valuable experience which should only be offered by your MS guys!

  12. mattd says:

    Doron,

    This might be a dumb question but… can you explain what WDF_SYNCHRONIZATION_SCOPE is and how it relates to sequenial queues? Thanks.

  13. Ishai says:

    WdfIoTargetSendInternalIoctlOthersSynchronously and WdfIoTargetFormatRequestForInternalIoctlOthers use different types to format the OtherArg* parameters.    What is the reason behind this difference?  Thanks.

  14. doronh says:

    matt:  I will get to your suggestion soon:

    Ishai:  the reason they are different is b/c there is no structure to these values, they are completey typeless.  For instance, the fields in the PIRP do not have to be pointers, even though they are PVOID.  For instance, I have seen the PVOID field treated as an INT.  So, all KMDF can do is copy the values over manually without interpretation.

  15. Ishai says:

    In both cases I send an internal non-standard ioctl with typeless parameters.   But if I send it synchronously, WDF lets me pass any value with a WDF_MEMORY_DESCRIPTOR where I can set the PVOID value as I wish (event an INT if the ioctl requires that)

    However if I want to format the request and send it asynchronously, I must allocate additional WDFMEMORY handles with WdfMemoryCreatePreallocated to achieve the same goal.

    So to restate the question – why does WdfIoTargetFormatRequestForInternalIoctlOthers require WDFMEMORY where WdfIoTargetSendInternalIoctlOthersSynchronously accepts a PWDF_MEMORY_DESCRIPTOR.

  16. doronh says:

    All "FormatFor" DDIs take a WDFMEMORY because they are potentially asynchronous and KMDF will make sure the memory is valid for the lifetime of the WDFREQUEST being sent so that cancelation is easier and memory corruption does not occur.

    All "SendSynchronously" DDIs can take a PVOID/PMDL/WDFMEMORY because they are synchronous and memory lifetime is not an issue becase the usage of the memory is bounded by scope.

    If you need to send something other then a PVOID in an Others parameter, then format an IO_STACK_LOCATION on your own and call WdfRequestWdmFormatUsingStackLocation().

  17. mattd says:

    Doron,

    You and Jake had some great talks online from last years WinHEC but I can no longer find where these are located. You made mention of them in your DevCon talk. Are they are no longer available online? Thanks.

  18. Kamala says:

    I recently updated a MS newsgroup post (link below) and thought I would post here too in hope of bringing it to your attention (assuming you can afford the time) –

    I am attempting to add secondary dump data to crash dumps and I am using KeRegisterBugCheckReasonCallback/ BugCheckSecondaryDumpDataCallback etc.  to accomplish this.  Once I got past the initial problems I had with passing appropriate data (output buffer page alignment etc.), I was getting the bugcheck callback twice as expected. IopInvokeSecondaryDumpDataCallbacks was calling

    IopWriteToDisk as expected. I also checked the return value of IopWriteToDisk and it wasn’t STATUS_UNSUCCESSFUL or STATUS_END_OF_FILE.  It always returns 0 (STATUS_SUCCESS).  Would it be right to assume that IopWriteToDisk successfully wrote to the crash dump if the return value is 0?  When I

    open the generated crash dump (in windbg) and run the .enumtag command, I get the following error –

    "Unable to start enumeration, HRESULT 0x80004002"

    Plus, when I open the generated crash dump in a hex editor, "TRGD" is at the tail end.  If I compare that will a crash dump that contains secondary dump data, I see "DumpBlob" followed by "TRGD".  This proves that my secondary dump data was never persisted to disk.  Am I missing something obvious?  Any input you have on this is much appreciated.

    http://msdn.microsoft.com/newsgroups/default.aspx?query=secondary+dump&d

    g=microsoft.public.development.device.drivers&cat=en-us-msdn-windev-wind

    dk&lang=en&cr=US&pt=&catlist=BC660915-5862-4C50-90C5-906EA14F77C0%2C3F4A

    33B0-DFB1-4EDB-A319-AA94AB5F92BB%2C774F24A2-F71F-425F-AC2B-DC48AB0DA5C9&

    dglist=&ptlist=&exp=&sloc=en-us

  19. doronh says:

    kamala, i don’t know the answer offhand.  if i were not on paternity leave, i would go ask the debugger folks myself….instead, osr.com has a windbg mailing which the debugger folks are on .  you should join and ask there.

    d

  20. Kamala says:

    Thanks, Doron!  I am already a member of the OSR WinDbg group and I brought this issue to their attention this morning.

    Kamala

  21. Kamala says:

    Thought I would update you on the secondary dump data issue.  It turns out, when I have my machine set to collect kernel memory dump and it falls back on minidump because of resource constraint, secondary dump data is not preserved.  Per Drew Bliss, this may have been fixed in newer OS versions.  Thanks for you help!

    Kamala

  22. matt-martin says:

    Is there a checked version of w2k sp4 urp1? I’ve searched everywhere and

    can not find a reference to it even existing.

    Is there a reason why some SP’s don’t seem too have checked builds while others do?

    I’m really only interested in the kernel and fltmgr, is there a way to

    obtain checked versions of these files?

    Any insight into MS’s policies regarding this would be appreciated.

    Thanks,

    M

  23. doronh says:

    matt, sorry, i don’t know.  i wish it were consistent as well.  I can ask around, esp w/the filt manager team.

    d

  24. matt-martin says:

    I guess there isn’t a checked version, anyhow, thanks for looking into it.

    m

  25. doronh says:

    Yeah, i couldn’t find it either.  Good information to stash away for later if I am ever asked again.

    thx

    d

  26. HustleDancer says:

    Doran:  I am still having problems with W2003 server/SP1 and XP/SP2 refusing to recognize a USB device plugged into a USB 2.0 port after some types of cable pull.  This occurs when multiple instances of the device (some times up to 8 of them) are attached via PCI/USB cards, and one gets pulled.  Sometimes we see just the one port refusing to recognize a re-plug of the same device or a fully different device.  Use of usb serial number does not appear to fix the problem.  We have seen posts about a possible problem between the Pnp/Power Manager and the individual USB chip/bus drivers being the culprit.  Any thoughts or ideas?

    Alan

  27. doronh says:

    sorry it took so long for me to respond.  i asked the usb guys and it sounds like an electrical issue on the hub you are using or a firmware issue on your device in the part where you implement the usb on the wire protocol.

    thx

    d

  28. VelcroILean says:

    Getting around System File Protection for purposes of driver development is made very easy by WinDbg’s .kdfiles command.

    It’s documented in the help files. Open the WinDbg Help file and search for .kdfiles.

    I’ve integrated the generation of the map file into my build environment and set up my WinDbg launching batch file to set   _NT_KD_FILES=<drivermapfile> automatically.  

    This saves me an extra re-boot every time I need to update an executable driver file on the target machine.

    John

  29. doronh says:

    .kdfiles rocks.  It has 2 limitations though.  The first is that it requires XP and later (which is not a big deal for most folks since Win2k is on the wane).  The second is that it cannot be used on files initially loaded by the boot loader. Both limitations are easy to deal with though, which is nice ;).

    I typically use .kdfiles with the -m option instead of a hardcoded map file.

    d

  30. rhog says:

    I am having an issue with a Biometric Sensor and a Video card placing a Monitor into suspend (sleep mode).

    We allow a user of a system to Log on or unlock the system by plaing their finger on a fingerprint reader. This is currently working very well if the system does not have the display in Sleep or suspend mode.  If it does the user is able to log on or unlock the system but the displace does not become active.  I need to some how query to see if the display is suspened and if so send a message to the system telling it to wakeup. Can you tell me if this is possible and if it is I woudl bbe grateful if you could steer me in the right direction to solve this?

  31. doronh says:

    When you detect that the user is present (let’s say when the swipe their finger across the reader), call PoSetSystemState(ES_USER_PRESENT) in the driver.  This will notify the OS that a user is present and will no longer consider the machine to be idle (which in this case would be turning on the monitor).  

    If the machine is in standby, you need to arm your device for wake when processing the Sx IRP (and your device has to support remote wake).  If you use KMDF, you can do this in one function call.  If you are interfacing with SMCLIB to appear as a smart card, we have a sample that we can send to you in email that shows you how to integrate SMCLIB functionality into a KMDF driver.

    d

  32. msftone says:

    hi doron

    Given there are alot of choices for driver frameworks (KMDF, WDM, pre-WDM, etc).

    I think a good article would be to help identify which framework should be used over another relative to a specific project need.  As an example, if i am doing a file system driver should i use KMDF or WDM? …..

    Key of the ask is to educate those of us in the field who are approaching a project and have to answer the question of "why not use X since X is newer than Y"

    🙂

  33. VC_RYK says:

    Hi Doron

    i want to see the DbgPrint output in WinDbg.

    i am using WinDbg on my machine itself..

    Thnak in advance

    RYK

  34. finewings says:

    I like your blog very useful, although I feel the font here are too small to read…