Welcome to MSDN Blogs Sign in | Join | Help

February 2006 - Posts

How to correctly initialize a UNICODE_STRING

In the past if you wanted to delcare a UNICODE_STRING and buffer on the stack, you had to manually declare the buffer and then initialize all the fields in the UNICODE_STRING, basically something like this #define SOME_SIZE WCHAR stringBuffer[SOME_SIZE]; Read More...
Posted Monday, February 27, 2006 5:01 PM by doronh | 0 Comments
Filed under:

ntstrsafe.h now contains safe functions for UNICODE_STRING too!

I don't think this is a well publicized feature, but the Server 2003 SP1 DDK contains a new version of ntstrsafe.h that now supports UNICODE_STRING. I pushed for this new functionality because nearly all ntoskrnl.exe exports which deal with a name expect Read More...
Posted Monday, February 27, 2006 2:08 PM by doronh | 2 Comments
Filed under:

How should I handle symbolic links and IRP_MN_SURPRISE_REMOVAL

For my final entry in surprise removal week (did anyone sense a theme :) ?), let's talk about symbolic links and surprise remove. The DDK docs state that you should not use a symbolic link with a PnP device, but I understand that practically speaking, Read More...
Posted Friday, February 24, 2006 10:53 AM by doronh | 1 Comments
Filed under:

How should I handle my hardware when processing IRP_MN_SURPRSISE_REMOVAL?

The quick answer answer that you must assume your hardware is present and at least probe the hardware to see if it responds. You might be thinking, "I thought surprise removal was only sent when my hardware was yanked from the machine." Not so, please Read More...
Posted Monday, February 20, 2006 3:53 PM by doronh | 0 Comments
Filed under:

Do I have to handle IRP_MN_SURPRISE_REMOVAL?

You might think that just because your device is root enumerated or is plugged into fix slot (llike PCI) and not in a hot plug bus (like USB or PCCARD/PCMCIA) that your driver will not get a IRP_MN_SURPRISE_REMOVAL irp. This would be a bad assumption Read More...
Posted Monday, February 20, 2006 3:32 PM by doronh | 5 Comments
Filed under:

Why does my device interface disappear when I replug my device back in?

This is a side affect of not unregistering your device interface during surprise removal . If you do not unregister during surprise removal, this can happen: Instance #1 is built up and start and registers the device interface Instance #1 gets surprise Read More...
Posted Monday, February 20, 2006 3:16 PM by doronh | 0 Comments
Filed under:

When should I disable my device interface & deregister with WMI?

Last week I talked about how a device interfaces and WMI instances are made unique by the kernel. Both of these constructs rely on the device instance path being unique within the system. So the question becomes, when is the device instance path no longer Read More...
Posted Monday, February 20, 2006 2:58 PM by doronh | 1 Comments
Filed under:

I like FORCEINLINE

For kernel mode code, if I have choice between using a #define or a FORCEINLINE function, the FORCEINLINE function wins every time. #defines have their place, especially for quotifying (the # operator) or concatenating (the ## operator), but they have Read More...
Posted Thursday, February 16, 2006 11:54 PM by doronh | 14 Comments
Filed under: ,

Why KMDF does not have a callback for IRP_MN_QUERY_POWER/SystemPowerState

I was going to blog about this after I had some KMDF entries under my belt, but Raymond Chen got things started today with his post about how Windows Vista is not letting applications veto a power transition to a low power state (Sx, see the Glossary). Read More...
Posted Thursday, February 16, 2006 10:40 PM by doronh | 2 Comments
Filed under:

How are WMI instance IDs guaranteed to be unique?

This is related to today's previous topic of how the manager makes device interface GUIDs unique. Let's now look at how the kernel implementation of WMI (or IRP_MJ_SYSTEM_CONTROL if you are dealing with PIRPs or WBEM to you user mode folks) works. When Read More...
Posted Thursday, February 16, 2006 5:13 PM by doronh | 2 Comments
Filed under:

How are device interface strings guaranteed to be unique?

When you register a device interface GUID, you get back a symbolic link name which is the link representing the instance of the device interface. The symbolic link that is returned has to be unique to your device, otherwise 2 devices sharing the same Read More...
Posted Thursday, February 16, 2006 12:28 PM by doronh | 1 Comments
Filed under:

Why am I not seeing any new device notifications when calling RegisterDeviceNotification?

Let's define this simple worker function which registers for device interface arrival notifications for a given handle (either an HWND or service HANDLE): HDEVNOTIFY RegisterInterfaceNotificationWorker( HANDLE Recipient, LPCGUID Guid, DWORD Flags ) { Read More...
Posted Wednesday, February 15, 2006 6:40 PM by doronh | 3 Comments
Filed under:

Glossary

This is meant to be an organic document that grows over time. If the term you are looking for is not in this a list, you should look at the DDK docs Class Driver : A driver, usually written by Microsoft, which generically controls devices of a certain Read More...
Posted Tuesday, February 14, 2006 8:58 PM by doronh | 3 Comments
Filed under:

\Device\Suggestions

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 Read More...
Posted Tuesday, February 14, 2006 11:21 PM by doronh | 34 Comments

PDOs, part 1

Definition: A PDO is a Physical Device Object. This entry is not going into how to enumerate a PDO or the rules involved in PDO enumeration and management. There are two types of PDOs. A raw PDO and a PDO which is not raw (e.g. cooked). Assume that the Read More...
Posted Tuesday, February 14, 2006 9:38 PM by doronh | 1 Comments
Filed under:

KMDF v1.1 announced and it supports Windows 2000!

We've been working on it since we RTW'ed v1.0 late last year and v1.1 is now "official." V1.1 contains minor bug fixes and, most importantly, official support for Windows 2000. Internally, the team wanted this in v1.0, but there was a snag or two along Read More...
Posted Tuesday, February 14, 2006 7:50 AM by doronh | 3 Comments
Filed under:

Intro

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 at MSFT for 8.5 years and counting... We own a 100+ year old house, so I have become intimately familiar with home repair ... and now search overstock.com Read More...
Posted Tuesday, February 14, 2006 12:58 AM by doronh | 2 Comments
 
Page view tracker