none
Why can't I attach to a hosted Powershell process with Visual Studio? RRS feed

  • Question

  • I have followed the proscribed instructions in this article every conceivable way, but have always been unable to attach to the process running my Powershell code:

    https://github.com/adamdriscoll/poshtools/wiki/Remote-Process-Attaching

    A little background on how I'm running it:

    Msiexec.exe is the parent process, which uses the Wix DTF framework to execute C# code.  And so, the true parent process of the Powershell code I'm running from the default runspace is RunDll32.exe.  Everything is being launched from an interactive session as a user with local administrative rights.

    Every time I try to attach to the process hosting the code, the attempt times out.  I have ensured that Msiexec.exe is launched from the same UAC elevation level as Visual Studio (elevated), but this doesn't help.  When I attempt to attach from the same console window I launched Msiexec from, I get:

    Enter-PSHostProcess : Unable to connect to application domain name DefaultAppDomain of process 13836.  Error: Timeout expired before connection could be made to namedpipe>..

    I've even tried invoking System.Diagnostics.Debugger.Launch() from my script, but this stalls in much the same way when I select my Visual Studio instance in which I have the solution open.

    Am I doing something wrong, or am I fundamentally tilting at windmills with how I'm executing the Powershell code?

    • Edited by CaryR Wednesday, September 27, 2017 10:38 PM
    • Moved by jrv Wednesday, September 27, 2017 11:04 PM correct forum
    Wednesday, September 27, 2017 10:35 PM

All replies

  • Hi CaryR,

    According to your description, I create a sample PS hosted application based on this document and then try attach the PowerShell process through Visual Studio -> Attach.

    But I don't find Msiexec.exe and RunDll32.exe in my process list. I also tried attach all PowerShell related process in my list and all of them could be attached successful without any error.

    I suggest you try execute your PowerShell script with Windows PowerShell first and then attach the Windows PowerShell process to check whether it could be run successful. Then please host your PS process on your application and attach your application process.

    If possible, please provide more detailed information to help us reproduce this issue, such as a sample PS hosted project and detailed steps that you do.

    Best Regards,
    Weiwei 


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, September 28, 2017 6:52 AM
  • When I run a very simple script from the powershell command prompt, I am able to attach to the process and hit a breakpoint which I set.  (I can't attach the screenshot yet, because for some reason my account isn't verified...)

    I have uploaded my sample project I am working on here:

    github.com/habeebtc/WixPowershell

    The PowershellCA project is what is hosting the powershell, and the 'SamplePowershell' Wix project is what executes it.  You'll find that the "Azure Login" dialog in the installer is what invokes the powershell (one of the first screens in the *.msi install, which is AllscriptsWixSetup.msi).

    The login button is what calls the powershell and first displays a Messagebox so that I can try attaching to the process.  At that moment you will see RunDll32.exe running with a path to the *.dll in the %TEMP% folder.

    Thursday, September 28, 2017 6:30 PM
  • I should also mention, when I switch to hosting the same very simple Powershell script hosted inside a C# console application, I am unable to debug.

    Here's basically my powershell script I have hosted in C#:

    param($session)

    Start-Sleep -s 60

    Write-Host "$session!"

    After attaching to the process I receive this message after the 60 second timeout elapses (and my breakpoint on the Write-Host statement is never hit):

    "Your app has entered a break state, but no code is currently executing that is supported by the selected debug engine (e.g. only native runtime code is executing)."

    Thursday, September 28, 2017 6:53 PM
  • Hi CaryR,

    I have clone your sample project but after I run the AllscriptsWiXSetup.msi and the Azure Login display, after I click the Login button, I don't get a messagebox and I also doesn't find the RunDll32.exe. And the HostPowershell project also loaeded failed in the solution. Could you please point me where I'm doing wrong?

    >> "Your app has entered a break state, but no code is currently executing that is supported by the selected debug engine (e.g. only native runtime code is executing)."

    Please check your Visual Studio to make sure it has installed PowerShell Tools extension and the "Enable Just my code" option in Tools -> Options -> Debugging settings has been checked.

    Best Regards,
    Weiwei


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, October 2, 2017 6:00 AM
  • Hello Weiwei,

    Following your instruction, I have enabled the flag for "Enable just my code", but I am still unable to attach to the HostPowershell.exe process (which I created as a simple C# console application).  I am not sure what to recommend to get this project to load, but it may be because I created this project in VS2017.  Possibly, you may need to copy-paste the code into a new console project if you're not on VS2017 (not sure).  

    With regards to the powershell code not running on your machine when the Login button is pressed, the *.msi creates a log in the %TEMP% folder, named like MSI####.log.  It may complain about not having some version of .Net installed.  The action name in the log will be, "ValidateAzureRMAccount".  Here's an excerpt from how my log looks (the exception being logged is what I am trying to debug by attaching to the running script):

    Action 8:56:20: ValidateAzureRMAccount. 
    Action start 8:56:20: ValidateAzureRMAccount.
    MSI (c) (EC:7C) [08:56:20:426]: Creating MSIHANDLE (1) of type 790542 for thread 20860
    MSI (c) (EC:10) [08:56:20:427]: Invoking remote custom action. DLL: C:\Users\CROYS\AppData\Local\Temp\MSIC45D.tmp, Entrypoint: ValidateAzureRMAccount
    MSI (c) (EC:98) [08:56:20:429]: Cloaking enabled.
    MSI (c) (EC:98) [08:56:20:429]: Attempting to enable all disabled privileges before calling Install on Server
    MSI (c) (EC:98) [08:56:20:429]: Connected to service for CA interface.
    MSI (c) (EC!B4) [08:56:20:504]: Creating MSIHANDLE (2) of type 790531 for thread 15796
    MSI (c) (EC!B4) [08:56:20:504]: Closing MSIHANDLE (2) of type 790531 for thread 15796
    MSI (c) (EC!B4) [08:56:20:659]: Creating MSIHANDLE (3) of type 790531 for thread 15796
    MSI (c) (EC!B4) [08:56:20:660]: Closing MSIHANDLE (3) of type 790531 for thread 15796
    MSI (c) (EC!B4) [08:56:20:690]: Creating MSIHANDLE (4) of type 790531 for thread 15796
    MSI (c) (EC!B4) [08:56:20:693]: Closing MSIHANDLE (4) of type 790531 for thread 15796
    MSI (c) (EC!B4) [08:56:20:892]: Creating MSIHANDLE (5) of type 790531 for thread 15796
    MSI (c) (EC!B4) [08:56:20:894]: PROPERTY CHANGE: Adding CELog-5996e property. Its value is 'Start Exec Powershell script AzureFunctions.ps1, function ValidateAzureRMAccount'.
    MSI (c) (EC!B4) [08:56:21:132]: Closing MSIHANDLE (5) of type 790531 for thread 15796
    MSI (c) (EC!B4) [08:58:02:971]: Creating MSIHANDLE (6) of type 790531 for thread 15796
    MSI (c) (EC!B4) [08:58:02:972]: PROPERTY CHANGE: Adding CELog-2f7ea property. Its value is 'Powershell Execution failed!'.
    MSI (c) (EC!B4) [08:58:02:972]: Creating MSIHANDLE (7) of type 790531 for thread 15796
    MSI (c) (EC!B4) [08:58:02:972]: PROPERTY CHANGE: Adding CELog-f79fc property. Its value is 'Cannot convert value "PSCELOGFB59D4C4" to type "System.Int32". Error: "Input string was not in a correct format."'.
    MSI (c) (EC!B4) [08:58:02:986]: Creating MSIHANDLE (8) of type 790531 for thread 15796
    MSI (c) (EC!B4) [08:58:02:986]: PROPERTY CHANGE: Adding CELog-8ded4 property. Its value is '   at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input)
       at System.Management.Automation.PowerShell.Worker.ConstructPipelineAndDoWork(Runspace rs, Boolean performSyncInvoke)
       at System.Management.Automation.PowerShell.Worker.CreateRunspaceIfNeededAndDoWork(Runspace rsToUse, Boolean isSync)
       at System.Management.Automation.PowerShell.CoreInvokeHelper[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
       at System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
       at System.Management.Automation.PowerShell.CoreInvoke[TOutput](IEnumerable input, PSDataCollection`1 output, PSInvocationSettings settings)
       at System.Management.Automation.PowerShell.Invoke(IEnumerable input, PSInvocationSettings settings)
       at System.Management.Automation.PowerShell.Invoke()
       at PowershellCA.CustomActions.ExecPowershell(Session
    MSI (c) (EC!B4) [08:58:03:003]: Closing MSIHANDLE (7) of type 790531 for thread 15796
    MSI (c) (EC!B4) [08:58:03:004]: Closing MSIHANDLE (6) of type 790531 for thread 15796
    MSI (c) (EC!B4) [08:58:03:004]: Closing MSIHANDLE (8) of type 790531 for thread 15796
    MSI (c) (EC:10) [08:58:03:037]: Closing MSIHANDLE (1) of type 790542 for thread 20860
    Action ended 8:58:03: ValidateAzureRMAccount. Return value 1.

    Monday, October 2, 2017 4:57 PM
  • Hi CaryR,

    Thanks for your response.

    According to your description, I create a sample Console application and copy the code from HostPowershell project and then build it, click the Console.exe from bin\Debug folder. Then after I attach process for the Console.exe and it attached successful.

    I'm also using VS2017 version 15.3.3. Please check your Visual Studio version. The latest version of Visual Studio 2017 is version 15.3.5, you could try upgrade to the latest version and try again.

    >> Enter-PSHostProcess : Unable to connect to application domain name DefaultAppDomain of process 13836.  Error: Timeout expired before connection could be made to namedpipe>..

    The error message mentioned "application domain name", does the project in another machine? Please run it on local machine to check whether there has any problem.

    Best Regards,
    Weiwei


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, October 3, 2017 3:10 AM
  • Hello WeiWei,

    All processes are on the same machine--my local dev laptop.

    My Visual Studio version is 15.3.3.  

    I receive the same issue as before, which is to say even in my simple HostPowershell.exe, I attach to the process with the VS2017 debugger and when the code is ready to continue, I receive:

    "Your app has entered a break state, but no code is currently executing that is supported by the selected debug engine (e.g. only native runtime code is executing)."

    I've confirmed that the "Enable just my code" option is still enabled.

    Perhaps you can tell me the steps you took to create an application hosting powershell, and how you attached to it to step through the Powershell script source?

    Tuesday, October 3, 2017 4:36 PM
  • Hi CaryR,

    >> "Your app has entered a break state, but no code is currently executing that is supported by the selected debug engine (e.g. only native runtime code is executing)."

    I also get this message when I try debug your application when we call the PowerShell script from C# code. This is because when we attach the host application (Console application) process, Visual Studio will debug it with the C# code rule, which need to load corresponding .pdb file. But PowerShell script doesn't have .pdb file. So the breakpoint in PowerShell script will not be hit.

    So if you just want to debug your PowerShell script, please right-click the PowerShell script in your project and choose "Execute as Script" or "Execute as script with parameters". Then the Visual Studio will start debug your PowerShell script and the breakpoints in this file will be hit.

    All above need install PowerShell Script Tools for Visual Studio extension.

    Best Regards,
    Weiwei


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, October 4, 2017 5:26 AM
  • Hi Weiwei,

    I am unable to debug the scripts as standalone scripts--or rather debugging them as standalone scripts as you describe will not accomplish what I am trying to accomplish.

    The reason I am hosting Powershell code as a part of an installer is because I would like to use the Msiexec.exe API from powershell, which requires a Session object passed to the code.  There's no way to obtain a valid Sesssion object, except when running as a part of the installer (it is contingent on a HWND, which is only valid underneath Msiexec.exe).  This is what allows me to drive the interaction between the installer UI and the powershell code.  Changing my script to run outside of Msiexec.exe negates the entire reason of debugging--I am trying to inspect the objects which trace their origins back to the HWND to the running installer.

    While your explanation sounds plausible as to why I can't enter a running powershell script hosted by another process, I have seen demos of this working.  Please see the following video of someone stepping through powershell code hosted by the Powershell ISE:

    https://www.youtube.com/watch?v=ZAG4BgEc8Ng

    So, this is supposed to work by design, but for some reason I am unable to make it work.

    Wednesday, October 4, 2017 6:00 PM
  • Hi CaryR,

    According to the video, I tested in VS2015 with the same code in video. It works fine in VS2015 with PowerShell ISE. But when I change to use Console application to invoke the PowerShell script, I could not debug the script in VS2015 any more. And in VS2017 I also could not debug the PowerShell ISE.

    I'm afraid that there has any problem on PowerShell Tools for Visual Studio extension. So I submit this issue to Q&A of this extension. I suggest you use VS2015 and PowerShell ISE to debug your script before the author response.

    https://marketplace.visualstudio.com/items?itemName=AdamRDriscoll.PowerShellToolsforVisualStudio2017-18561#qna

    Best Regards,
    Weiwei


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Proposed as answer by Fletch Zhou Friday, October 6, 2017 8:34 AM
    Thursday, October 5, 2017 3:17 AM
  • Weiwei,

    Thanks for your time, and getting the question in front of the right audience.

    Thanks,

    Cary

    Thursday, October 5, 2017 3:28 AM