Powershell: Missing DLL files when running in a 32-bit mode

user_12194785 0
Viewed 235

In order to get the DLL files running under a certain process I am using the following line of code:

$Modules += Get-Process -Id $ProcessId | Select-Object -ExpandProperty Modules

This line of code works perfectly fine when running in a 64-bit mode. However, when using a 32-bit mode I have noticed that the same process returns less modules than in a 64-bit mode.

Why is this happening ? and since i need to run my script in a 32-bit mode, is there any other method of getting the requested DLL files ?

powershell
1 Answers

As stated in the comments on the question, 32-bit processes cannot access modules of 64-bit processes, so you cannot use your command as-is from 32-bit PowerShell if the target process is a 64-bit process.

In fact, if you try to access a 64-bit Windows PowerShell instance from a 32-bit one with your command, you get an explicit error message to that effect, at least on Windows 10 with Windows PowerShell v5.1:

A 32 bit processes cannot access modules of a 64 bit process.

As a suboptimal workaround, you can invoke 64-bit Windows PowerShell via its CLI (powershell.exe) from your 32-bit instance:

$ps64 = "$($PSHOME -replace '\\SysWOW64\\', '\\SysNative\\')\powershell.exe" 
& $ps64 -noprofile { (Get-Process -Id 1468 | Select-Object -ExpandProperty Modules) }

The workaround is suboptimal in two respects:

  • It involves creation of a new PowerShell instance in a new process, which is slow.

  • More importantly, the objects that are returned are only approximations of the System.Diagnostics.ProcessModule instances that direct invocation would return.

    • Specifically, they are [pscustomobject] instances - with a type name of Deserialized.System.Diagnostics.ProcessModule to indicate their source - that have properties of the same names as the original objects, with static copies of their values (which may themselves be such [pscustomobject] instances; also, these instances lack the methods that the original objects have.

    • That said, if all you need is to access properties such as .ModuleName or .FileName, you shouldn't have a problem.

user_453750
Related