CITRIX Still Use Legacy Network Redirector Model On Windows 10 x86

NTFSD
1

This Question is very specific to CITRIX environment so only CITRIX developers on this forum can entertain otherwise simply ignore>>

I have mini-filter driver and which does scanning of files after modification.
On Windows 7, 8.1 & 10 - x64 machines successfully able to monitor/scan files from published drive because PICADM.SYS => “\device\PicaDriveRedirector” is symbolic link with “\Device\MUP” or PICA is registered with MUP so we gets Pre & Post File I/O calls in driver.

But on Windows 7, 8.1 & 10 - 32 bit O.S observed very strange issues, Looks like CITRIX still using LEGACY file system redirection model. i.e They have separate device for network file redirection and which is not registered with “MUP”, due to that FltMgr didn’t come in picture.

Can any one please tell:

  1. What are the parameters CITRIX follow to switch legacy Vs FltMgr
  2. Why FltMgr model on x64 and LEGACY on x86?

Thanks in advance.

2

You are right.
I set a breakpoint on 32 bit picadm’s IRP_MJ_CREATE and there was no MUP in the stack.

00 9dcea970 82a52593 picadm+0xb010
01 9dcea988 82c622a9 nt!IofCallDriver+0x63
02 9dceaa60 82c41ac5 nt!IopParseDevice+0xed7
03 9dceaadc 82c51ed6 nt!ObpLookupObjectName+0x4fa
04 9dceab38 82c489b4 nt!ObOpenObjectByName+0x165
05 9dceabb4 82c6c218 nt!IopCreateFile+0x673
06 9dceac00 82a591ea nt!NtCreateFile+0x34
07 9dceac00 771270b4 nt!KiFastCallEntry+0x12a
08 03ffd90c 771255d4 ntdll!KiFastSystemCallRet
09 03ffd910 753caa21 ntdll!NtCreateFile+0xc

While on the 64 bit it had MUP on the stack( I removed a third party driver from the call stack )

19 fffff88003609c90 fffff880222e9a9e picadm+0x3960
…
22 fffff8800360a760 fffff880222e9a9e mup!MupCreate+0x8c8
…
2b fffff8800360b2d0 fffff80010247ad5 nt!IopParseDevice+0x173c
2c fffff8800360b4b0 fffff80010257448 nt!ObpLookupObjectName+0x806
2d fffff8800360b600 fffff800102525ee nt!ObOpenObjectByName+0x258
2e fffff8800360b6d0 fffff800102b89eb nt!IopCreateFile+0x37c
2f fffff8800360b770 fffff800101d25f5 nt!IoCreateFileEx+0xeb

I believe this is a question for the CITRIX support.

If the old code works there is no incentive to invest in its modification and testing if that doesn’t add any functionality.

3

Hmm… my first reply did do it through the OSR list engine, so I repeat it here

You are right.
I set a breakpoint on 32 bit picadm’s IRP_MJ_CREATE and there was no MUP on stack

00 9dcea970 82a52593 picadm+0xb010
01 9dcea988 82c622a9 nt!IofCallDriver+0x63
02 9dceaa60 82c41ac5 nt!IopParseDevice+0xed7
03 9dceaadc 82c51ed6 nt!ObpLookupObjectName+0x4fa
04 9dceab38 82c489b4 nt!ObOpenObjectByName+0x165
05 9dceabb4 82c6c218 nt!IopCreateFile+0x673
06 9dceac00 82a591ea nt!NtCreateFile+0x34
07 9dceac00 771270b4 nt!KiFastCallEntry+0x12a
08 03ffd90c 771255d4 ntdll!KiFastSystemCallRet
09 03ffd910 753caa21 ntdll!NtCreateFile+0xc

While on 64 bit there was a call to MUP

19 fffff88003609c90 fffff880222e9a9e picadm+0x3960
…
22 fffff8800360a760 fffff880222e9a9e mup!MupCreate+0x8c8
…
2b fffff8800360b2d0 fffff80010247ad5 nt!IopParseDevice+0x173c
2c fffff8800360b4b0 fffff80010257448 nt!ObpLookupObjectName+0x806
2d fffff8800360b600 fffff800102525ee nt!ObOpenObjectByName+0x258
2e fffff8800360b6d0 fffff800102b89eb nt!IopCreateFile+0x37c
2f fffff8800360b770 fffff800101d25f5 nt!IoCreateFileEx+0xeb

4

Thanks Slava Imameev for quick reply.

I don’t think its feasible to keep two driver source one x86 and other for x64.

Can any one please suggest what will be the possible solutions for such situation instead of keeping two driver source.

5

One point of clarification here. This is not a question of fltmgr vs.
legacy implementation since Citrix has implemented a redirector, whether
it is a mini-redirector (not FltMgr based) or a full redirector. It is a
matter of how they are registering with MUP. You would need to inquire
with them as to why they decided to do what they have done on x86 vs.
x64.

Pete

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

------ Original Message ------
From: xxxxx@gmail.com
To: “Windows File Systems Devs Interest List”
Sent: 8/23/2016 11:26:29 PM
Subject: [ntfsd] CITRIX Still Use Legacy Network Redirector Model On
Windows 10 x86

><< This Question is very specific to CITRIX environment so only CITRIX
>developers on this forum can entertain otherwise simply ignore>>
>
>I have mini-filter driver and which does scanning of files after
>modification.
>On Windows 7, 8.1 & 10 - x64 machines successfully able to monitor/scan
>files from published drive because PICADM.SYS =>
>“\device\PicaDriveRedirector” is symbolic link with “\Device\MUP” or
>PICA is registered with MUP so we gets Pre & Post File I/O calls in
>driver.
>
>But on Windows 7, 8.1 & 10 - 32 bit O.S observed very strange issues,
>Looks like CITRIX still using LEGACY file system redirection model. i.e
>They have separate device for network file redirection and which is not
>registered with “MUP”, due to that FltMgr didn’t come in picture.
>
>Can any one please tell:
> 1. What are the parameters CITRIX follow to switch legacy Vs FltMgr
> 2. Why FltMgr model on x64 and LEGACY on x86?
>
>Thanks in advance.
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>