How to Call TpmVscMgr.exe (a 32-Bit Utility) from PowerShell Running in 64-Bit Mode

I'm having trouble running TpmVscMgr.exe from a PowerShell script that runs in 64-bit mode on Windows 10. I gather that TpmVscMgr.exe is a 32-bit utility, as witnessed by the fact that it resides in C:\Windows\System32. Trying to run it straight-up from my script leads to an exception saying that the cmdlet cannot be found. I have also tried this method just to destroy a TPM slot for starters:

Add-Type -AssemblyName PresentationFramework
[System.Windows.MessageBox]::Show('Test')

try
{
	$32bitPSCode =
	{
		$tpmVscMgrFullyQualified = (Join-Path ([System.Environment]::SystemDirectory) "TpmVscMgr.exe")
		$cmdLine = "$tpmVscMgrFullyQualified destroy /instance ROOT\SMARTCARDREADER
Add-Type -AssemblyName PresentationFramework
[System.Windows.MessageBox]::Show('Test')
try
{
$32bitPSCode =
{
$tpmVscMgrFullyQualified = (Join-Path ([System.Environment]::SystemDirectory) "TpmVscMgr.exe")
$cmdLine = "$tpmVscMgrFullyQualified destroy /instance ROOT\SMARTCARDREADER\0000"
Invoke-Expression $cmdLine
}
Invoke-Command -ScriptBlock $32bitPSCode -ConfigurationName microsoft.powershell32 -ComputerName .
}
catch
{
[System.Windows.MessageBox]::Show($_)
}
00"
		Invoke-Expression $cmdLine
	}

	Invoke-Command -ScriptBlock $32bitPSCode -ConfigurationName microsoft.powershell32 -ComputerName .
}
catch
{
	[System.Windows.MessageBox]::Show($_)
}

This does not even seem to lead to an exception. The script seems to get into some kind of hang, followed by terminating with a console message that says,

[...] Connecting to remote server ... failed with the following error message : The client cannot connect to the destination specified in the
request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service
running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and
configure the WinRM service: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic.
    + CategoryInfo          : OpenError: (...:String) [], PSRemotingTransportException
    + FullyQualifiedErrorId : CannotConnect,PSSessionStateBroke

There is a misconception here. C:\Windows\System32 isn't the 32-bit directory, when seen from a 64-bit application. It's the native 64-bit directory which MSFT named like this for compatibility reasons (sigh). Only when a 32-bit application looks at C:\Windows\System32, it will see the actual 32-bit directory (see File System Redirector).

When you enter (Get-Command TpmVscMgr).Source command in a 64-bit PowerShell console, it outputs C:\WINDOWS\system32\tpmvscmgr.exe, which actually means TpmVscMgr is a 64-bit application! And there is no 32-bit version (Get-Command TpmVscMgr fails, when run from a 32-bit PowerShell console).

It follows that you actually don't need to use Invoke-Command to run PowerShell in 32-bit mode and you can simply call the command TpmVscMgr without further ado. You don't even need to specify it's full path, because native commands in system directory will be found automatically.

TpmVscMgr destroy /instance ROOT\SMARTCARDREADER
TpmVscMgr destroy /instance ROOT\SMARTCARDREADER
TpmVscMgr destroy /instance ROOT\SMARTCARDREADER\0000
000
000

Links:

• File System Redirector

• Why do 64-bit DLLs go to System32 and 32-bit DLLs to SysWoW64 on 64-bit Windows?