First, a correction to my previous remlock post, where I said that you must still compile your driver as chk before you can see the benefits of the driver verifier's new remlock checking functionality.  You don't need a chk version of your driver!  The owner of DV informed me that a fre version of the driver (which means the fre version of IO_REMOVE_LOCK) will be fully verified.  For this to work, DV allocates its own debug IO_REMOVE_LOCK structure under the covers and redirects the remlock related calls to use this internal pointer. 

This has an interesting side affect though, the remlock in your driver is never udpated to reflect the acuires and releases.  This means that !remlock will not show you the current I/O count for your remlock if you break in and try to see what the current I/O count is (which you might do if your call to IoReleaseRemoveLockAndWait never returns due to a leaked reference).  Unfortunately, there is nothing you can do to get the under the internal verifier version of the remlock, but we are aware of the problem and hope to find a resolution soon.  Alternatively, if you release a reference you did not acquire, you will get the internal verifier remlock pointer in the !analyze output; parameter 2 will contain this internal pointer.

The other change related to remove locks is the definition of IoAcquireRemoveLock.  In DDKs previous to the WDK, __FILE__ and __LINE__ were always passed to the underlying worker function.  This meant that these constants were in your release binary.  Not a big deal to some developers, but a very big deal to others.  To mitigate this, the macro which defines IoAcquireRemoveLock has been changed in the WDK to not include this information:

#if DBG
#define IoAcquireRemoveLock(RemoveLock, Tag) \
        IoAcquireRemoveLockEx(RemoveLock, Tag, __FILE__, __LINE__, sizeof (IO_REMOVE_LOCK))
#else
#define IoAcquireRemoveLock(RemoveLock, Tag) \
        IoAcquireRemoveLockEx(RemoveLock, Tag, "", 1, sizeof (IO_REMOVE_LOCK))
#endif