In a lab setting of multiple Windows machines, several machines were unable to create a named pipe server:
Windows Server 2012 R2 build 9600
Windows 10 Pro build 10240
It is unclear why some of these machines failed, because other machines with the same OS were not affected.
This issue was solved by modifying the ObjectAttributes.Attributes flag being passed to NtCreateNamedPipeFile. This change did not impact previously working machines so it appears safe for general use.
Background:
Inspecting the output from the system call, ntCreateNamedPipeFile() returned the following:
Retval: 3221225530
Status: -1073741766
There was no named pipe present in the PowerShell output: Get-ChildItem -Path "\\.\pipe\"
To rule out machine specific issues, an alternate named pipe server was built from the Named Pipe C++ example from Microsoft: https://learn.microsoft.com/en-us/windows/win32/ipc/multithreaded-pipe-server
Notably, this example uses CreateNamedPipeW versus NtCreateNamedPipeFile. The named pipe was successfully created with retval=0, and the pipe was observed in the PowerShell output: Get-ChildItem -Path "\\.\pipe\"
Now, there were 2 executables with different retvals from the same machine.
Knowing that CreateNamedPipeW eventually calls NtCreateNamedPipeFile, WinDBG was used to trace the call.
The outcome of the investigation was that CreateNamedPipeW was passing a 0x40 in ObjectAttributes.Attributes flag, whereas go-winio was passing 0x0. The issue was resolved by setting ObjectAttributes.Attributes to 0x40, corresponding to OBJ_CASE_INSENSITIVE.
overall this looks good, DCO task happy you will have to sign your commits:
git rebase HEAD~7 --signoff may work, or you squash all the commits and sign that
In a lab setting of multiple Windows machines, several machines were unable to create a named pipe server:
This issue was solved by modifying the ObjectAttributes.Attributes flag being passed to
NtCreateNamedPipeFile
. This change did not impact previously working machines so it appears safe for general use.Background: Inspecting the output from the system call, ntCreateNamedPipeFile() returned the following: Retval: 3221225530 Status: -1073741766 There was no named pipe present in the PowerShell output:
Get-ChildItem -Path "\\.\pipe\"
To rule out machine specific issues, an alternate named pipe server was built from the Named Pipe C++ example from Microsoft: https://learn.microsoft.com/en-us/windows/win32/ipc/multithreaded-pipe-server Notably, this example uses
CreateNamedPipeW
versusNtCreateNamedPipeFile
. The named pipe was successfully created with retval=0, and the pipe was observed in the PowerShell output:Get-ChildItem -Path "\\.\pipe\"
Now, there were 2 executables with different retvals from the same machine. Knowing that
CreateNamedPipeW
eventually callsNtCreateNamedPipeFile
, WinDBG was used to trace the call. The outcome of the investigation was thatCreateNamedPipeW
was passing a 0x40 in ObjectAttributes.Attributes flag, whereas go-winio was passing 0x0. The issue was resolved by setting ObjectAttributes.Attributes to 0x40, corresponding to OBJ_CASE_INSENSITIVE.