PowerShell Universal crashes after upgrade to 1.5

PowerShell Universal crashes after upgrade to 1.5

Version: 1.5
Issue:
The PowerShell Universal service will not start properly when upgrading from 1.4 to 1.5. The following error is shown in the log. 


Unhandled exception. System.InvalidCastException: Unable to cast object of type 'System.Collections.Generic.Dictionary`2[System.String,LiteDB.BsonValue]' to type 'System.String'.

   at lambda_method(Closure , Object , Object )

   at LiteDB.BsonMapper.DeserializeObject(Type type, Object obj, BsonDocument value)

   at LiteDB.BsonMapper.Deserialize(Type type, BsonValue value)

   at LiteDB.BsonMapper.ToObject(Type type, BsonDocument doc)

   at LiteDB.BsonMapper.ToObject[T](BsonDocument doc)

   at LiteDB.LiteCollection`1.Find(Query query, Int32 skip, Int32 limit)+MoveNext()

   at LiteDB.LiteQueryable`1.ToEnumerable()+MoveNext()

   at System.Collections.Generic.LargeArrayBuilder`1.AddRange(IEnumerable`1 items)

   at System.Collections.Generic.EnumerableHelpers.ToArray[T](IEnumerable`1 source)

   at LiteDB.LiteQueryable`1.ToArray()

   at UniversalAutomation.LiteDBTable`1.ToArray() in D:\a\universal\universal\src\UniversalAutomation.LiteDB\LiteDBDatabase.cs:line 508

   at UniversalAutomation.LiteDBDatabase.Seed() in D:\a\universal\universal\src\UniversalAutomation.LiteDB\LiteDBDatabase.cs:line 138

   at UniversalAutomation.StartupService.StartAsync(CancellationToken cancellationToken) in D:\a\universal\universal\src\Universal.Server\Services\StartupService.cs:line 80

   at Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellationToken)

   at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)

   at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)

   at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(IHost host)

   at Universal.Server.Program.Main(String[] args) in D:\a\universal\universal\src\Universal.Server\Program.cs:line 31

Root Cause:
A property was changed within one of the classes within PowerShell Universal's source code that conflicts with the 1.4 database. This property is related to jobs that have been run using alternate credentials. If you run any job with alternate credentials, you will encounter this error. 
Workaround:
The immediate workaround is to delete the %ProgramData%\UniversalAutomation\database.db file. It will be recreated on start up of 1.5. Deleting the database to cause a loss of the following data:
  1. Job History and Output
  2. Identities
  3. App Tokens



    • Related Articles

    • PowerShell Universal Service crashes on startup after an upgrade to 1.4.6

      Version: PowerShell Universal 1.4.6 Issue The PowerShell Universal service will crash with the following error in Event Viewer.  Application: Universal.Server.exe CoreCLR Version: 4.700.19.56402 .NET Core Version: 3.1.0 Description: The process was ...

    • KB0041 - About Templates

      Purpose The purpose of this article is to provide a timeline around the Template functionality of PowerShell Universal. Background Templates were introduced to provide a starting point for newcomers to PowerShell Universal. They have since been ...

    • KB0078 - Service fails to start during PowerShell Universal v5 Upgrade when using SQLite and MSI

      Scope Users that are upgrading from PowerShell Universal v4 to PowerShell Universal v5 using the MSI and SQLite persistence database. Problem The service may not start in a timely manner and cause the MSI process to fail. Root Cause PowerShell ...

    • KB0059 - Error During PowerShell Universal Install or Upgrade

      Affected Versions - All PowerShell Universal Versions Problem When running the PowerShell Universal MSI on a system that had an older version of the product installed, the user will see an error message that states "The folder path 'C:' contains an ...

    • KB0066 - Get-WMIObject cmdlet not working

      Scope This article applies to any scenario where the Get-WMIObject cmdlet is expected to be available and functioning within a PowerShell Universal instance. Effectively, this article will only apply to instances that run under the Windows operating ...