In the call stack above, `WRusr.dll` is calling `CallNamedPipeW` with their pipe `\\.\pipe\WRSynUM2` from a thread created by their `DllMain`. This ends up unintentionally doing COM, because `CreateFileW` uses a brokered fallback code if the normal path (`NtCreateFile`) fails with `ERROR_ACCESS_DENIED` (which it does here, because of our sandboxing). It is the brokered fallback code that does COM here and this code is part of Microsoft's implementation for `CreateFileW`. It sounds a bit crazy that `CreateFileW` is doing COM but here we are. I believe that the easiest option outside blocking would be to ask Webroot to do a first call to `NtCreateFile` in order to fail early if they are denied access to the pipe. This way they would only end up calling `CallNamedPipeW` if they already know that `CreateFileW` will not do COM...
Bug 1895174 Comment 32 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
In the call stack above, `WRusr.dll` is calling `CallNamedPipeW` with their pipe `\\.\pipe\WRSynUM2` from a thread created by their `DllMain`. This ends up unintentionally doing COM, because `CreateFileW` uses a brokered fallback code if the normal path (`NtCreateFile`) fails with `ERROR_ACCESS_DENIED` (which it does here, because of our sandboxing). It is the brokered fallback code that does COM here and this code is part of Microsoft's implementation for `CreateFileW`. It sounds a bit crazy that `CreateFileW` is doing COM but here we are. I believe that the easiest option outside blocking would be to ask Webroot to do a first call to `NtCreateFile` in order to fail early if they are denied access to the pipe. This way they would only end up calling `CallNamedPipeW` if they already know that `CreateFileW` will not do COM... If I nop-out the call to `CallNamedPipeW` I can play the video without trouble.
In the call stack above, `WRusr.dll` is calling `CallNamedPipeW` with their pipe `\\.\pipe\WRSynUM2` from a thread created by their `DllMain`. This ends up unintentionally doing COM, because `CreateFileW` uses a brokered fallback code if the normal path (using `NtCreateFile`) fails with `ERROR_ACCESS_DENIED` (which it does here, because of our sandboxing). It is the brokered fallback code that does COM here and this code is part of Microsoft's implementation for `CreateFileW`. It sounds a bit crazy that `CreateFileW` is doing COM but here we are. I believe that the easiest option outside blocking would be to ask Webroot to do a first call to `NtCreateFile` in order to fail early if they are denied access to the pipe. This way they would only end up calling `CallNamedPipeW` if they already know that `CreateFileW` will not do COM... If I nop-out the call to `CallNamedPipeW` I can play the video without trouble.
In the call stack above, `WRusr.dll` is calling `CallNamedPipeW` with their pipe `\\.\pipe\WRSynUM2` from a thread created by their `DllMain`. This ends up unintentionally doing COM, because `CreateFileW` uses a brokered fallback code if the normal path (using `NtCreateFile`) fails with `ERROR_ACCESS_DENIED` (which it does here, because of our sandboxing). It is the brokered fallback code that does COM here, and this code is part of Microsoft's implementation for `CreateFileW`. It sounds a bit crazy that `CreateFileW` is doing COM but here we are. I believe that the easiest option outside blocking would be to ask Webroot to do a first call to `NtCreateFile` in order to fail early if they are denied access to the pipe. This way they would only end up calling `CallNamedPipeW` if they already know that `CreateFileW` will not do COM... If I nop-out the call to `CallNamedPipeW` I can play the video without trouble.
In the call stack above, `WRusr.dll` is calling `CallNamedPipeW` with their pipe `\\.\pipe\WRSynUM2` from a thread created by their `DllMain`. This ends up unintentionally doing COM, because `CreateFileW` uses a brokered fallback code if the normal path (using `NtCreateFile`) fails with `ERROR_ACCESS_DENIED` (which it does here, because of our sandboxing). It is the brokered fallback code that does COM here, and this code is part of Microsoft's implementation for `CreateFileW`. It sounds a bit crazy that `CreateFileW` is doing COM but here we are. I believe that the easiest option outside blocking `WRusr.dll` would be to ask Webroot to do a first call to `NtCreateFile` in order to fail early if they are denied access to the pipe. This way they would only end up calling `CallNamedPipeW` if they already know that `CreateFileW` will not do COM... If I nop-out the call to `CallNamedPipeW` I can play the video without trouble.
In the call stack above, `WRusr.dll` is calling `CallNamedPipeW` with their pipe `\\.\pipe\WRSynUM2` from a thread created by their `DllMain`. This ends up unintentionally doing COM, because `CreateFileW` uses a brokered fallback code if the normal path (using `NtCreateFile`) fails with `ERROR_ACCESS_DENIED` (which it does here, because of our sandboxing). It is the brokered fallback code that does COM here, and this code is part of Microsoft's implementation for `CreateFileW`. It sounds a bit crazy that `CreateFileW` is doing COM but here we are. I believe that the easiest option outside blocking `WRusr.dll` would be to ask Webroot to use `NtCreateFile`, `TransactNamedPipe`, `CloseHandle` instead of `CallNamedPipeW` to avoid the brokered fallback code ([*Calling CallNamedPipe is equivalent to calling the CreateFile (or WaitNamedPipe, if CreateFile cannot open the pipe immediately), TransactNamedPipe, and CloseHandle functions.*](https://learn.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-callnamedpipew))... If I nop-out the call to `CallNamedPipeW` I can play the video without trouble.