Eryk Sun <[email protected]> added the comment:
> there shouldn't be any problem with 33-bit/64-bit here. Windows
> doesn't separate processes like that.
Accessing the MainModule property of a .NET Process object raises an exception
if the current process is 32-bit and the process is 64-bit [1]. This is because
a 32-bit process can't sensibly read the PEB data of a 64-bit process, such as
the loader's module data.
It seems we have to P/Invoke QueryFullProcessImageName (which makes an
NtQueryInformationProcess system call instead of reading data directly). We
already have p.Handle, so the process doesn't have to be opened. Here's an
example in 32-bit posh (i.e.
%SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe):
$MethodDefinition = @"
[DllImport("kernel32.dll", SetLastError=true, CharSet=CharSet.Unicode)]
public static extern bool QueryFullProcessImageName(
[In]IntPtr hProcess, [In]int dwFlags, [Out]StringBuilder lpExeName,
ref int lpdwSize);
"@
$Kernel32 = Add-Type -Using "System.Text" -MemberDefinition `
$MethodDefinition -Name "Kernel32" -Namespace "Win32" -PassThru
$p = [System.Diagnostics.Process]::GetProcessesByName("explorer")[0]
$size = 32768
$name = [System.Text.StringBuilder]($size)
32-bit posh can't directly read the executable name:
PS C:\> $p.MainModule.FileName -eq $null
True
But QueryFullProcessImageName works fine:
PS C:\> $Kernel32::QueryFullProcessImageName($p.Handle, 0, $name,
[ref]$size)
True
PS C:\> $name.ToString()
C:\Windows\explorer.exe
[1]: https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.process
----------
nosy: +eryksun
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue34980>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
