1

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\0000"
        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
Altus
  • 23
  • 4
  • Using Invoke-Command with `-ComputerName` requires that the WinRM service is up and configured on the target, even if it's localhost that you're trying to invoke upon. The error message is giving you the resolution for this. – Scepticalist Mar 07 '23 at 08:57
  • Can I somehow use Invoke-Command without -ComputerName? I get an exception when I try this. – Altus Mar 07 '23 at 10:24
  • duplicates: [Why can't I launch telnet.exe from a Windows 8 command prompt?](https://superuser.com/q/463395/241386), [Run Windows batch commands in 32-bit mode](https://stackoverflow.com/q/47697743/995714), [Executable "C:\Windows\System32\Fodhelper.exe" not found](https://stackoverflow.com/q/66262735/995714). Avoid the 32-bit cmd and powershell – phuclv Mar 07 '23 at 11:42

1 Answers1

0

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\0000

Links:

zett42
  • 25,437
  • 3
  • 35
  • 72
  • I tried calling TpmVscMgr with and w/o any qualification. It gave me the "cmdlet not found" exception in either case. – Altus Mar 07 '23 at 10:05
  • @Altus I can reproduce the problem only when I run 32-bit version of PowerShell. Are you sure you are running 64-bit PowerShell? You might accidentally run 32-bit PS, when you launch it from a 32-bit app. – zett42 Mar 07 '23 at 10:23
  • @Altus To verify you are actually running 64-bit PS, enter `$env:PROCESSOR_ARCHITECTURE`. This should output `AMD64`. If you get `x86`, you are actually running 32-bit PS. – zett42 Mar 07 '23 at 10:30
  • It gives me x86. Thanks for pointing it out. – Altus Mar 07 '23 at 10:57
  • @Altus If the problem is solved, please click on big checkmark button on the left to accept this answer. Otherwise please let me know what you are still having problem with. – zett42 Mar 07 '23 at 21:44
  • The answer did not really answer but the comment did. I clicked the check mark. Thx for reminding me. – Altus Mar 08 '23 at 08:07