Server Endpoint (Peripheral Control) blocks Virtual Hard Disk (FSLogix Profile Container)

Do you have anything under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CoDeviceInstallers

Thank you for your post. Yes. A lot. Whats is it?

If I recall, the Sophos Device Control Coinstaller - sdcoinstaller.dll exists so that a new device can be disabled at install time by drvinst.exe, rather than appearing and then disappearing as it's disabled afterwards by Device Control. This DLL essentially remove the window of time where the device is accessible and handles to it can be obtained.  Then you have to potentially reboot to disable it.

The values are created by the sdcservice "Sophos Device Control" service if I remember - A Process Monitor log would reveal that and I think they only exist when you actually block a device, which explains why when you don't block it's OK.

If you back the key to a reg file, clear out these does it work, the danger is the SDCservice will write the values back in.  Would it be possible to delete these at the point the vhdx is mounted as a test?

I backup up the keys and deleted them. After that i was able to logon without any problems. Profile Container was loaded.
I tried 10 times and everything was fine.
After i reinstalled the keys the Problem was right back.

This drives me nuts.
When i allow everything except for secure removaable Storage Registry is cleared except for the 2 keys you can see at the bottom of the screenshot and Profile Containers do not work.
When i block everything except for secure Removeable Storage these keys stay in Registry as you see at the  top of the screenshot.
profilecontainer doesnt work.

When i delete the 2 keys manually it works fine. So we narrowed it down to two registry keys. Thats cool!!!

Question is. Why does Sophos not recognise that is has blocked something and where exactly are these two keys come from

Ok its the  {4d36e967-e325-11ce-bfc1-08002be10318} Reg Key. To exclude it in Perepheral Control i have to Allow rem. strage and sec. rem. storage. 



Disk Drives
Class = DiskDrive
ClassGuid = {4d36e967-e325-11ce-bfc1-08002be10318}
This class includes hard disk drives. See also the HDC and SCSIAdapter classes

I did just run a PML when enabling blocking of storage devices and you do see sdcservice.exe setting the keys:

Likewise, when you disable the storage device blocking/policy, sdcservice.exe deletes the keys again:

Then when you plugin a USB stick for example at least the first time, the drvinst.exe process is created by the "DeviceInstall" service:

C:\WINDOWS\system32\svchost.exe -k DcomLaunch -p -s DeviceInstall

It is this that loads the co-installers that are registered for the class of device being inserted.

This is all Windows SetupAPI, so the log file: C:\Windows\INF\setupapi.dev.log is of relevance here.  You can increase the logging of the Windows SetupAPI with registry keys if needed but I see:

ndv: {Core Device Install} 20:14:39.99
dvi: {Install Device - USBSTOR\DISK&VEN_SANDISK&PROD_CRUZER_BLADE&REV_1.00\4C530000280118218365&0} 20:14:39.999
dvi: Device Status: 0x01802400 [0x01 - 0xc0000495]
dvi: Config Flags: 0x00000000
dvi: Parent Device: USB\VID_0781&PID_5567\4C530000280118218365
dvi: {DIF_ALLOW_INSTALL} 20:14:40.024
dvi: Using exported function 'CoDeviceInstall' in module 'C:\WINDOWS\system32\sdccoinstaller.dll'.
dvi: CoInstaller 1 == sdccoinstaller.dll
dvi: CoInstaller 1: Enter 20:14:40.081
dvi: CoInstaller 1: Exit
dvi: Default installer: Enter 20:14:40.087
dvi: Default installer: Exit
dvi: {DIF_ALLOW_INSTALL - exit(0xe000020e)} 20:14:40.092

You see the exe calling the CoDeviceInstall exported function in sdccoinstaller.dll which I guess prevents the install.

Having allowed the device, though, I don't see drvinst.exe get called again,and the setupapi.dev.log isn't updated to back this up. I guess it can be blocked without "installing" the device and going through the setupapi the second time around.

I do see SDCService, spawn the cli tool used by Device Control to enabled/disable devices. E.g.

"C:\Program Files (x86)\Sophos\Sophos Anti-Virus\SDCDevCon.exe" disable USBSTOR\DISK&VEN_SANDISK&PROD_CRUZER_BLADE&REV_1.00\4C530000280118218365&0

This would suggest, that it's not so much the act of the co-installer being loaded by the drvinst.exe process but just the presence of the registry key.  To test this hypothesis: If you were to enable blocking again, but:

1. Rename the sdccoinstaller.dll under \windows\system32\ do you still see the problem?

2. With the {4d36e967-e325-11ce-bfc1-08002be10318} registry value, if you blank out the value (DLL names) for this, do you still see the issue?

Is the problem that if there is a registration for the DiskDrive Class GUID, irrelevant if the referenced DLL exists or is even a value this causes the issue? 

Thank you for your detailed analysis.

1. Renaming the sdccoinstaller.dll ==> No change. Still blocking

2. Clearing the registry Value ==> No change. Still blocking.

It seems that the simple existence of the key is sufficient to block the device, right?

Well that's interesting and would suggest it's not a Sophos issue. Well not something they have control of if you want to hook into the Setup API with a co-installer in order to block the setup of certain class of device before they get installed rather than after the event which may cause issues and the need for reboots.

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/registering-a-class-co-installer and associated pages detail some of this.

To me it does feel like a OS bug if just the presence of the registry key is the issue as it would suggest anyone registering a coinstaller for the class GUID you mention would also have this issue. 

It's not like a bug in the sdccoinstaller.dll which is the one piece of Sophos code in this workflow short of the "registration" as this code is never loaded if it's not referenced.

I think the options are:

1. Disable any removable storage blocking as a way of the registry key not to exist. Not great.

2. Somehow orchestrate for the key to not exist at the point the vhdx in question is used. 

Maybe an app compat shim (sdb) could be created (MS Application Compatibility Toolkit) to "hide" the registry by redirecting it from the process that reads the key values or maybe you could shim the 32-bit sdcservice.exe process from writing the keys in the location as Device Control would still "work" without these keys.

E.g. The "fix" you might want to consider is "VirtualRegistry", the parameters for it might be something like

ADDREDIRECT(HKLM\SYSTEM\CurrentControlSet\Control\CoDeviceInstallers^HKLM\Software\sophos\fix)

In theory, when the policy came down, sdcservice would write the values into the fix path instead.  All quite hacky I guess but could be an interesting exercise. Tamper prevents registering app compat shims on Sophos processes but with TP disabled it can be done.

I believe Device control is currently being migrated from SAV to the Core agent component.  There is a chance that when that happens, this maybe fixed due to a change as I suspect coinstallers have possibly had their day.

The coinstaller part of Sophos isn't fully required I suspect, t just makes it a better experience on that first setup of a device.

Hope it helps.

Well that's interesting and would suggest it's not a Sophos issue. Well not something they have control of if you want to hook into the Setup API with a co-installer in order to block the setup of certain class of device before they get installed rather than after the event which may cause issues and the need for reboots.

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/registering-a-class-co-installer and associated pages detail some of this.

To me it does feel like a OS bug if just the presence of the registry key is the issue as it would suggest anyone registering a coinstaller for the class GUID you mention would also have this issue. 

It's not like a bug in the sdccoinstaller.dll which is the one piece of Sophos code in this workflow short of the "registration" as this code is never loaded if it's not referenced.

I think the options are:

1. Disable any removable storage blocking as a way of the registry key not to exist. Not great.

2. Somehow orchestrate for the key to not exist at the point the vhdx in question is used. 

Maybe an app compat shim (sdb) could be created (MS Application Compatibility Toolkit) to "hide" the registry by redirecting it from the process that reads the key values or maybe you could shim the 32-bit sdcservice.exe process from writing the keys in the location as Device Control would still "work" without these keys.

E.g. The "fix" you might want to consider is "VirtualRegistry", the parameters for it might be something like

ADDREDIRECT(HKLM\SYSTEM\CurrentControlSet\Control\CoDeviceInstallers^HKLM\Software\sophos\fix)

In theory, when the policy came down, sdcservice would write the values into the fix path instead.  All quite hacky I guess but could be an interesting exercise. Tamper prevents registering app compat shims on Sophos processes but with TP disabled it can be done.

I believe Device control is currently being migrated from SAV to the Core agent component.  There is a chance that when that happens, this maybe fixed due to a change as I suspect coinstallers have possibly had their day.

The coinstaller part of Sophos isn't fully required I suspect, t just makes it a better experience on that first setup of a device.

Hope it helps.