Fixing “Debug adapter process has terminated unexpectedly” error in VSCode for PowerShell

VSCode is the primary tool that Microsoft provides on Linux and Mac OS to edit and debug PowerShell scripts. Yet, on MacOS, with default installation, you are likely to get the “Debug adapter process has terminated unexpectedly” when you try running your scripts.

However, to fix this issue you simply need to install OpenSSL on your Mac running VSCode as described here.

Once this is done, simply:

  1. Click File / Open and open the folder containing the PowerShell script,
  2. Click the script that you want to edit in the left-hand pane,
  3. Set breakpoints where you want them by clicking on the margin by the corresponding script line,
  4. Press F5 or click the run button in the editor:

Debugging PowerShell scripts on Mac OS X in VSCode

Happy scripting!

Categories: Powershell

Enabling Intellisense for PowerShell cmdlets in VSCode on Mac OS X

VSCode is the primary way to edit and debug PowerShell scripts on Mac OS and Linux. If you do not have it yet, follow these instructions on GitHub on installing VSCode on Mac OS/Linux/Windows and adding its PowerShell extension.

Once you are done with that, you can create a new or open an existing PS1 file, however, you might still get “No suggestions” error when you try to get intellisense for cmdlets:

VSCode on Mac no suggestions

This is because this functionality actually requires OpenSSL. Here’s how you add it to your system:

Install Homebrew

Homebrew is Mac’s most popular package manager. To install it:

  1. Open a Terminal window,
  2. Install Mac OS command-line developer tools (xcode) by pasting the following command and pressing Enter:
    xcode-select --install

    Install Mac OS command-line developer tools xcode
  3. Install Homebrew package manager by pasting the following command:
    ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
    Installing Homebrew Mac OS package manager
  4. Double-check that the installation is successful by running

    brew doctor

    System ready to brew

Install OpenSSL

Now install OpenSSL on Mac OS by simply pasting the following command to the Terminal window:

brew install openssl

 Install openssl on Mac OS X with homebrew

Verify PowerShell cmdlet intellisense in VSCode

  1. Start VSCode,
  2. Open a ps1 file or save the file that you have as .ps1,
  3. Verify that PowerShell is selected as the language mode at the bottom right of the VSCode window:PowerShell language mode in VSCode
  4. Type Get- and you will see the intellisense window popping up with the list of available Get- cmdlets:VSCode with intellisense for PowerShell cmdlets

Categories: Powershell

Run PowerShell on Mac OS X

As you have probably heard by now, Microsoft has just open-sourced PowerShell and made it available for Linux and Mac OS X. In this blog post, I will take you through the steps to download, install and run PowerShell on a Mac.

Download and Install PowerShell for Mac OX

  1. Go to PowerShell github project: https://github.com/PowerShell/PowerShell
  2. Scroll down to the Get PowerShell section and download .pkg:

Download OS X pkg file for PowerShell

3. Locate the newly downloaded file in Downloads, right-click it and click Open:

Install PowerShell pkg on Mac OS X

4. You will be warned that this is a file from the Internet and then prompted for your local administrative password, then go through the installation wizard.

Run PowerShell on Mac OS X

PowerShell is a command-prompt in your terminal window, so to start it:

  1. Start the Terminal application,
  2. Now you can simply type powershell as a command and this will start the PowerShell engine and move you from the bash prompt ($) to the PowerShell prompt (PS):
    Starting PowerShell prompt on Mac OS X in bash Terminal

  3. That is it! You can now type a PowerShell command and see the output. For example, here’s Get-Process:
    Get-Process powershell command on Mac OS X

If you are new to PowerShell, see the Learning PowerShell page on GitHub.

Categories: Powershell

Temporary Post Used For Theme Detection (c7259616-4c95-413a-8141-113440c5eeab – 3bfe001a-32de-4114-a6b4-4005b770f6d7)

This is a temporary post that was not deleted. Please delete this manually. (ddae0643-8b1c-4107-80be-282fe283e924 – 3bfe001a-32de-4114-a6b4-4005b770f6d7)

Categories: Powershell

Getting Started with openHAB

Adam Driscoll's Blog - Wed, 02-Dec-15 18:24

openHAB is an open-source home automation project, aimed to be vendor and technology agnostic. It integrates with all kinds of devices and platforms. It also allows you to create rules and scripts to trigger when certain conditions are met. It offers a simple, built-in UI and native apps for Android and iOS. In this post we’ll look at what it takes to get up and running with openHAB and start communicating with an Insteon device.

The first step is to download the openHAB runtime core and addons. The runtime core has all the guts to get the system up and running. The system is Java based so you’ll need Java installed. This also means it should work on any platform that supports Java. The addon package allows you to selectively choose what openHAB loads so you only have the components that you really need in your system.

Runtime and Addon Downloads

Runtime and Addon Downloads

Another handy little tool to download is the openHAB Designer. It has some syntax highlighting and validation for the openHAB file types and reads the openHAB directory structure to present it in an IDE-like fashion.


After you’ve downloaded the packages, unzip the runtime core package to a good location. Once this is extracted, you’ll want to bring in the addons that you require for your configuration. The addons come out of the addon package and individual ones can be plopped into the addons directory of the runtime core folder structure. I only needed Insteon but grabbed a couple other ones. To integrate with various systems, you’ll want the “binding” addon for that system. The binding has the knowledge of how to communicate with that system. I also grabbed a couple persistence addons. These allow you to configure data persistence of the devices in your home for reporting. They aren’t required for the system to function.

Addons Directory

Addons Directory

Once the addons are installed, you’ll want to create a new configuration file for openHAB. In the configurations directory, you’ll need to create a copy of openhab_default.cfg and rename it openhab.cfg.


You can then change all the settings you need for various bindings, persistence or the system in general. Each of the bindings have examples in the cfg file so you can just uncomment the line and move ahead. Here’s the configuration for my Insteon PLM. It’s connected to a USB (COM4) port on my machine.


Next, you’ll want to setup devices and groups. This is accomplished by creating a .items file in the items folder. It can have any name as long as the extension is .items. Groups are just logical groupings and can be nested. Items are actual devices located throughout the house. They can be part of multiple groups. For example, my basement lights are part of the basement group and the lights group. A full description of the items file syntax can be found on the openHAB wiki. Here’s an example of my .items file open in the openHAB Designer.


Once items are configured, you’ll want to setup a sitemap. A sitemap defines how the UI of your openHAB setup will look. There are a bunch of controls like text, switches, selections and images. For a full list, check out the openHAB wiki. It seems pretty simple but I’m sure with a complex configuration it can get pretty gnarly. Here’s a simple sitemap that has a single page with a switch to turn off and on my basement lights.


After all this is configured, you can start up the openHAB server by running setup.bat in the root folder. Once running, you’ll be able to access the UI through a web browser at http://localhost:8080/openhab.app.


They also offer a Android and iOS app. I installed it on my phone and had to configure the external\internal URL. If you didn’t setup credentials (which is by default), you can leave those blank. Once connected it looks very similar to the web app but native to the phone.


So far, it looks like a really neat solution. It turns on and off my basement light just fine; even from my phone. It’s a bit of a learning curve getting started but seems really powerful. I have a few more Insteon devices lying around that I’ll get hooked up so I’ll see how that progresses. Apparently, it can integrate with Nest as well so I will have to get that up and running too.


Categories: Powershell

Reading Temperature from a Google Nest Thermostat with PowerShell

Adam Driscoll's Blog - Tue, 01-Dec-15 16:35

I recently acquired a Google Nest thermostat (on sale at Target!). Even before buying one I was already thinking about the automation possibilities. Google provides a REST interface for the Nest device. It’s accessible via OAuth and very easy to consume. The core tenant of their API is that there are very few endpoints and a single data model for multiple devices. In this post we’ll look at how to get up and running with the Google Nest REST API.


First, you need to create a developer account. Once this is done you need to create a new application under your developer account. It asks you a few questions about the types of devices and permissions you’ll need and from there you are ready to start interacting with your Nest device.


On the right hand side of the application page, you’ll see a couple text boxes with some key information in them. The first Authorization URL box would be the URL that you send the end user to. This prompts the user to authenticate and give permission to the application to access their device.


After clicking accept, the user will be presented with a PIN code page. This PIN needs to be provided back to the calling application. It will be inserted into the Access Token URL in place of the AUTHORIZATION_TOKEN portion of the URL provided in the Authorization Token URL on the application page.


The application, or PowerShell in this example, can then invoke the access token URL with the authorization token and it will receive an access token. This access token can then be provided to the various endpoints available in the Nest REST API.

Below, you can see the first command receives the access token, Next, it calls the devices endpoint with the auth key set to the value of the access_token. The returned value is the devices data model that includes all the information about the devices accessible to the calling application and tied to the specified user’s account. As you can see, I returned the current state of my HVAC system and the ambient tempature surrounding the thermostat.


There’s tons of nifty information for each device. There are also a bunch of cool devices to interact with.


There is also the ability to work with virtual devices so that an actual device isn’t needed. It’s pretty sweet to see this type of home automation so simply accessible. I hope to stumble upon some new devices in the near future and come up with some cool integrations.

Categories: Powershell

Digging into PowerShell Direct

Adam Driscoll's Blog - Wed, 25-Nov-15 11:42

Available in Windows 10 and the Windows Server 2016 Technical Preview, there is a new feature of PowerShell and Hyper-V that enables you to connect to guest machines that lack network access: PowerShell Direct. The standard PSSession cmdlets along with Invoke-Command now offer a VMID and VMName parameter. Simply run any of these commands as you normally would with a remote machine and you have access to a remoting session to the guest. It worked perfectly for me.


After playing with it a bit, I was curious to find out just how it works. The first place I looked was in the guest where there is a new service installed called the “Hyper-V VM Session Service” (vmicvmsession). It’s initially stopped but when I attempted to connect via Enter-PSSession from the host machine, the service was automatically started.

On the client end, I popped open .NET Reflector and dug into the Enter-PSSession cmdlet. This cmdlet can be found in the System.Management.Automation.dll. This is where you will see the new properties for VMName and VMID.


When a VM name or ID is specified, a new HyperVSocketConnectionInfo class is used rather than the typical WSManConnectionInfo class.


There were a bunch of interesting classes associated with Hyper-V remoting. They implement the glue necessary to open the connection and allow the PowerShell remoting proctol to go over the Hyper-V socket.


One class that is interesting is the RemoteSessionHyperVSocketClient class. It’s responsible for initiating the socket connection to the guest. In the constructor to the client, it instantiates a HyperVSocketEndPoint to pass to the Socket constructor.


Interesting to note is the protocol type is listed as ICMP and the socket family is a 0x22 magic number. Looking at the AddressFamily enumeration, this address family is not listed. Also, the address family is not registered with IANA. The endpoint’s serialized value is a combination of the address family, VMID and service ID. The service ID depends on whether or not this is the first connection to the guest.


On the first connection, the first step is to send the username and domain name.


Next a string is sent to indicate whether or not a password will be sent and then the password is sent. Afterwards, the client checks for a failure string.


Once this socket is open, standard PS Remoting protocols seem to be used just as you would with a WSMan connection.

Overall, it’s a super handy feature and it’s interesting to see how it’s being accomplished. I do wonder what the magical address family 0x22 will be called or if it will remain 0x22.



Categories: Powershell

Upcoming features in PowerShell Tools for Visual Studio

Adam Driscoll's Blog - Tue, 01-Sep-15 18:53

Long time no blog! I wanted to showcase a couple neat features coming to PowerShell Tools for Visual Studio. My hope is that we can get some feedback before pushing to the gallery for the world to enjoy.

Windows Forms Support for PowerShell

The Windows Form designer is handy for throwing together some drag and drop UI. I spent some time futzing with creating a CodeDOM provider for PowerShell. The Windows Form designer talks CodeDOM so we need to translate the PowerShell AST into a CodeDOM format in order to get the form designer to understand a PowerShell script. The other half of the equation is taking an existing CodeDOM and translating it into a functioning PowerShell script. Some of the challenges were that, until recently, PowerShell didn’t support classes so we had to fake it. Right now the CodeDOM provider is targeting PowerShell v3+. It uses the AST to create CodeDOM CompileUnits.

Once you have the latest build installed, you will have access to a new item template (need a new icon!).


Adding a new file of this type will create two files on disk. One is the designer code. The other is the event handling and execution file. The designer file contains all the code to render the UI and hook up the event handlers found in the other file. The execution file invokes the designer code and then shows the UI.





The designer file shouldn’t be edited by hand. The form designer is using the PoshTools CodeDOM provider to generate that on the fly.

Double clicking the form in the Solution Explorer window will show an error. Still trying to nail this one down!


To fix the error, just add references to System.Drawing and System.Windows.Forms.


From there you should be able to drag and drop items from the Toolbox on the form. Adjusting the properties should work. You can also hook up event handlers by doing actions like double clicking on buttons.

Would love to hear feedback! I need to fix the issue with the references before this will be committed to the main branch.

PowerShell Command Explorer

One of the neat tools in the PowerShell ISE is the command browser. It allows you to view different modules and the module within them. It also allows you to select different parameters and sets, view help and execute commands. Well thanks to Erwin de Vreugd, we now have that functionality within PoshTools!

After installing the updated build, you can access the Command Explorer by naviation to View->Other Windows->PowerShell Command Explorer. It provides very similar functionality to what is in the PowerShell ISE. This feature is looking very complete and will be merged into the main branch in a couple days. Check it out below!


Please play and provide feedback.

Categories: Powershell

Thread Slivers eBook at Amazon

Syndicate content