$Error is populated with unexpected errors during debugging

[benj_wisco]

I'm running the trial version of PowerShell Studio Version 4.2.91 on Windows 8.1 Enterprise x64.

When stepping through specific scripts, the $Error variable gets populated with the following error.

>> $Error
You cannot call a method on a null-valued expression.
At line:1 char:1
+ $^.GetType().FullName
+ ~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull


Each time I step or hit another breakpoint, the another one of these errors gets added to $Error. No matter where I put the breakpoints, it happens. I even set the first breakpoint at the first line of the script which can be a simple variable assignment, or write host.

When I am debugging and an error occurs, it is mingled in with these "null-value" errors that are generated. After a while it becomes frustrating.

Some of the unsuccessful things I have tried are

• Upgrade PowerShell Studio
  Disable all breakpoints, save and close PowerShell Studio, then try again
  Commenting out the entire script except one or two simple commands
  Deleting everything in the editor and just a couple simple commands
  Changing the Powershell Studio options back to their defaults (I added some assemblies)

I ran into the problem again today and tried to figure it out again. I copy/pasted the script I am working on into a new file within Powershell Studio. The new copy does not have the same issue. Figuring the problem was something in the file, I did a WinMerge to spot the difference. WinMerge revealed only whitespace differences. I made changes to the original file so it matched the new file, but I still have the same issue. So it appears that the problem is not in the script I'm working on, but something else.

Any ideas? I have used PowerGui for years, but the lack of support is making me move to something else. I'd love to buy PowerShell Studio and use it going forward, but things like this have me on the fence.

script error.png (162.07 KiB) Viewed 5222 times

[SAPIEN Support Forums]

This is an automated post. A real person will respond soon.

Thank you for posting, benj_wisco.

Did you remember to include the following?

• 1. Product, version and build (e.g. Product: PrimalScript 2014, Version & Build: 7.0.46. Version and build information can be found in the product's About box accessed by clicking the blue icon with the 'i' in the upper right hand corner of the ribbon.)
  2. Specify if you are running a 32 or 64 bit version
  3. Specify your operating system and if it is 32 or 64 bit.
  4. Attach a screenshot if your issue can be seen on the screen
  5. Attach a zip file if you have multiple files (crash reports, log entries, etc.) related to your issue.

If not, please take a moment to edit your original post or reply to this one.

*** Make sure you do not post any licensing information ***

[benj_wisco]

I think I may have found the reason I am running into issues. I did a binary diff and found there is a difference right at the beginning of the file. Looks like PowerShell Studio and the standard ISE encode the file as UTF-8 (EF BB BF). PowerGui uses FF FE which appears to be UTF-16.

Is there any feature in PowerShell Studio to change the encoding automatically? Or am I going to need to find and convert these before opening them in Powershell Studio?

[davidc]

You can change the file's encoding in the status bar of PowerShell Studio:

Encoding.png (7.81 KiB) Viewed 5218 times

We will need to investigate why $Error is causing an error message.

David

[benj_wisco]

Thanks for pointing out that entry on the status bar. I totally missed that.

After changing the script to UTF-8, I am still getting the errors. I compared the files again, and now they are binary identical.

I tried a few more things. If I copy the file to another location and keep the filename the same, I get the errors. If I then rename the file, I the errors do not occur.

So it seems like PowerShell Studio is caching something based on the filename.

[davidc]

We found the cause of the message. The entry you see is the result of the debugger querying for variable type information on a null value. This will be resolved in the next service release of the product.

David

[benj_wisco]

Thanks!