A Hole In My Head

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

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...

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?

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.

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 :)

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.

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>

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!

Doron,

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

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

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.

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.

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

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

Kamala

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

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

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

m

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

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

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?

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"

:-)

Hi Doron

i want to see the DbgPrint output in WinDbg.

i am using WinDbg on my machine itself..

Thnak in advance

RYK

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