Last updated on August 28, 2017

Recently we had a report in the dbatools project: there was an issue installing from the PowerShell Gallery (via Install-Module.)

Error “Invalid characters in path.”

We had a few scattered notifications of the issue and even one of the dbatools developers affected internally, but it proved to be a stubborn bug and the people involved had tried numerous methods in tracking it down.

We knew that one of the paths being provided to Windows was bad as a part of our module was bad, but the error message sucked and everything worked almost everywhere; we were really confused about what was going on.

It was clear that like any new issue it was a product of new code and changes to the project, but it was unclear which of the hundreds and hundreds of new additions was the source were the culprit.

We had been adding new things at a frenetic pace and this was not something that came up during the standard build process… the final count was 185+ files which might have something to do with this error.

I finally was able to get the source of the problem through attaching my new favorite program dnSpy to my PowerShell process, and I wanted to show you how to do it too.

Process

First, you need to download and extract dnSpy :

• You can browse the project here: https://github.com/0xd4d/dnSpy
• They make it easy to download the release here https://github.com/0xd4d/dnSpy/releases (grab dnSpy.zip)
• Extract the archive and locate dnspy.exe
  • Launch dnspy.exe – you may have to run dnSpy as an administrator to attach to processes or rewrite DLLs, I always launch it as administrator.
    
• Switch to a ready PowerShell window with your command
• From the debug menu, choose “Attach to Process…”
• Find your powershell.exe in the list, and choose “Attach”
  
• Back in your PowerShell window, run your command, you should see a new colored bar on the bottom of the dnSpy window indicating the attachment worked and it is running.
  
• Your PowerShell command should fail, and dnSpy should throw the exception and wait for input.
  
• Click the “Call Stack” tab.
  
• Right Click in the Call Stack area and make sure “Show Parameter Values” is checked.
  
• Success!!

You should now be able to read the methods that were called to get you to this error, and hopefully be able to suss out which methods got which parameters!

Further reading for dbatools problems:

When the module loaded and was analyzed, one of our strings in our psm1 file was interpreted as a filepath (but only in WMF 5.0, as stated 5.1 does not have this issue.)

The team was interested in keeping the module installation and setup process as speedy as possible and in that vein the following tweet and blog post came up

• https://twitter.com/bielawb/status/831266955889872898
• https://becomelotr.wordpress.com/2017/02/13/expensive-dot-sourcing/

From the article:

Solution? There are few options (like pipe Get-Content to Invoke-Expression), but I ended up with dot-sourcing a script block created from content of the script.

It looks like while this was (and probably is) a great idea, in certain versions of Install-Module it will actually interpret the dot in the dot sourcing as the start of a path, and will attempt to evaluate it as such, throwing an absolute tizz.

In the meantime, dbatools has made changes to effectively do the same thing without using a dot prefix for the line (even though WMF 5.1 is not affected by this issue) and thankfully with a few other changes one of our core contributors Fred was able to find a fix without losing too much time.