Home > Software design >  Why does PowerShell think C:\Windows\System32\WDI doesn't exist? How can I copy these log fi
Why does PowerShell think C:\Windows\System32\WDI doesn't exist? How can I copy these log fi

Time:03-27

I know that C:\Windows\System32\WDI exists and has contents. We need to copy these contents from hundreds of machines for security analysis. We tried:

Copy-Item 'C:\Windows\System32\WDI' -Destination .\my_output_dir\wdi -recurse

This works on my personal computer (I think I have myself permissions for system32 though the gui), but not for my colleague on other machines.

On other machines, we get an error:

Copy-Item : Cannot find path 'C:\Windows\System32\WDI' because it does not exist.
At line:1 char:1
  Copy-Item 'C:\Windows\System32\WDI' -Destination .\my_output_dir\wdi  ...
  ~~~~~~~~~~~~~~~~~
      CategoryInfo          : ObjectNotFound: (C:\Windows\System32\WDI:String) [Copy-Item], ItemNotFoundException
      FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.CopyItemCommand

It's not feasible to go into the GUI on every machine to give myself the necessary permissions. How can this be achieved purely through powershell? We have administrative credentials.

CodePudding user response:

The likeliest explanation is that the inability to find the directory is due to running in 32-bit PowerShell sessions on 64-bit systems: the System32 directory that 32-bit processes see doesn't have a WDI subdirectory.

You have two options:

  • Make sure that you use 64-bit PowerShell sessions everywhere.

  • Construct the directory path conditionally, so that in 32-bit sessions it accesses the directory via the SysNative folder, which refers to the true, (paradoxically named) 64-bit System32 folder; using Get-ChildItem as an example:

Get-ChildItem "$env:SystemRoot\$(('SysNative', 'System32')[[Environment]::Is64BitProcess])\WDI"

Note:

  • If you still need support for the long-obsolete v2 of PowerShell, substitute $env:ProgramFiles -notlike '*(x86)' for [Environment]::Is64BitProcess.

  • Accessing the files and directories in the WDI directory requires elevation (running as admin).

  • Related