There is a bug in the fslogix driver in combination with markany.

MarkAny is DRM software.

If FSLogix is configured in the VDI virtual machine, it works without any problems.

However, if you write data to the VHD mount area of FSLogix, such as the desktop after installing MarkAny DRM, the explorer stops.

The MarkAny DRM development team analyzed the dump for this issue and replied that they were sure there was a bug in FSLogix.

Below is the original text received via email.

Thank you for the dump.  We have concluded our analysis of the dump and it categorically points to a bug in the FsLogix driver.

I see that you have passed the dump to FsLogix, so we encourage you to share this email with the FsLogix support team.

In interoperability testing with the FsLogix development team at the recent Microsoft “Plugfest” event, the FSLogix team found a similar issue to this one in their driver – although the symptoms were very different.  They might welcome further information (and this data point might be a useful way to get past the FsLogix front line support team).

The key issue is that under certain circumstances the FsLogix Driver (a low altitude driver) is issuing a FltCreate with a NULL Instance, which means that the create enters the top of the Filter stack and causes FESF to deadlock.

Specifically looking at the dump we see the OsrIsolate Filter at a higher altitude than the FsLogix driver:

FLT_FILTER: ffff9c8e8dd71010 "mds_kernel" "144795"
FLT_FILTER: ffff9c8e8ddb9010 "OsrIsolate" "144700.5"
FLT_FILTER: ffff9c8e8da9a010 "frxdrvvt" "132700"

The version of FSLogix, information from resource tables:

CompanyName:      FSLogix, Inc.
        ProductName:      Microsoft FSLogix Apps
        InternalName:     frxdrvvt.sys
        OriginalFilename: frxdrvvt.sys
        ProductVersion:   2.9
        FileVersion:      2.9.8440.42104
 
In your dump, in thread ffff9c8e93db2080 we see that a rename (IRP ffff9c8e99a43050) had been processed by FESF and is being processed by FsLogix.  FsLogix has issued a create and this has passed through mds_kernel and is blocked in OsrIsolate.

If FsLogix had specified the correct Instance the create would not have gone to mds_kernel and OsrIsolate

nt!KiSwapContext+0x76
nt!KiSwapThread+0x500
nt!KiCommitThreadWait+0x14f
nt!KeWaitForSingleObject+0x233
OsrIsolate!IsolInFlightOperationDone+0x274 [C:\bbgit\fesf\src\Isolate\SetInfo.cpp @ 2098]
OsrIsolate!IsolFsdCreate+0x9aa [C:\bbgit\fesf\src\Isolate\Create.cpp @ 702]
OsrIsolate!IsolPreCreate+0x1a8 [C:\bbgit\fesf\src\Isolate\Create.cpp @ 115]
FLTMGR!FltpPerformPreCallbacksWorker+0x36c
FLTMGR!FltpPassThroughInternal+0xca
FLTMGR!FltpCreate+0x310
nt!IofCallDriver+0x55
nt!IoCallDriverWithTracing+0x34
nt!IopParseDevice+0x11bb
nt!ObpLookupObjectName+0x3fe
nt!ObOpenObjectByNameEx+0x1fa
nt!IopCreateFile+0x132c
nt!IoCreateFileEx+0x11d
FLTMGR!FltpCreateFile+0x16f
FLTMGR!FltCreateFileEx+0x91
mds_kernel+0xcca9
mds_kernel+0xc37a
FLTMGR!FltpPerformPreCallbacksWorker+0x36c
FLTMGR!FltpPassThroughInternal+0xca
FLTMGR!FltpCreate+0x310
nt!IofCallDriver+0x55
nt!IoCallDriverWithTracing+0x34
nt!IopParseDevice+0x11bb
nt!ObpLookupObjectName+0x3fe
nt!ObOpenObjectByNameEx+0x1fa
nt!IopCreateFile+0x132c
nt!IoCreateFileEx+0x11d
FLTMGR!FltpCreateFile+0x16f
FLTMGR!FltCreateFileEx2+0xe7
frxdrvvt+0xd7df
frxdrvvt+0xf9d6
frxdrvvt+0x1329a
frxdrvvt+0x135d2
FLTMGR!FltpPerformPreCallbacksWorker+0x36c
FLTMGR!FltpPassThroughInternal+0xca
FLTMGR!FltpPassThrough+0x541
FLTMGR!FltpDispatch+0x8b
nt!IofCallDriver+0x55
nt!IopCallDriverReference+0xd0
nt!NtSetInformationFile+0xb85
nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffff8407`ce7bf4c0)
ntdll!NtSetInformationFile+0x14

Armed with this information the FsLogix team should be able to immediately fix this bug and issue a new version of their driver

I hope that helps,

---------------------------------------------------------------------------------
end message.

Looking forward to help from the FSLogix team.