Previously I had a trial version of 2.0.13 installed and it worked great. I uninstalled it and and deleted all the related Octopus folders and registry entries.
Now when I try to install version 2.3.6 I get this error
Previously I had a trial version of 2.0.13 installed and it worked great. I uninstalled it and and deleted all the related Octopus folders and registry entries.
Now when I try to install version 2.3.6 I get this error
2 instances, String instanceName) in c:\Builds\RavenDB-Stable\Raven.Database\Indexing\WorkContext.cs:line 373 at Raven.Database.Indexing.WorkContext.SetupPerformanceCounter(String name) in c:\Builds\RavenDB-Stable\Raven.Database\Indexing\WorkContext.cs:line 337 at Raven.Database.Indexing.WorkContext.Init(String name) in c:\Builds\RavenDB-Stable\Raven.Database\Indexing\WorkContext.cs:line 390 at Raven.Database.DocumentDatabase..ctor(InMemoryRavenConfiguration configuration, TransportState transportState) in c:\Builds\RavenDB-Stable\Raven.Database\DocumentDatabase.cs:line 252 at Raven.Client.Embedded.EmbeddableDocumentStore.InitializeInternal() in c:\Builds\RavenDB-Stable\Raven.Client.Embedded\EmbeddableDocumentStore.cs:line 218 at Raven.Client.Document.DocumentStore.Initialize() in c:\Builds\RavenDB-Stable\Raven.Client.Lightweight\Document\DocumentStore.cs:line 459 at Octopus.Server.Storage.StorageEngine.InitializeStore() in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Server\Storage\StorageEngine.cs:line 125 at System.Lazy
1.CreateValue()1.LazyInitValue() at Octopus.Server.Storage.StorageEngine.Start() in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Server\Storage\StorageEngine.cs:line 41 at Octopus.Server.Commands.AdminCommand.Start() in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Server\Commands\AdminCommand.cs:line 69 at Octopus.Shared.Startup.ConsoleHost.Run(Action
1 start, Action shutdown) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Shared\Startup\ConsoleHost.cs:line 36Hi Bob,
Unfortunately the Windows Performance Counters can get corrupted from time-to-time, at a guess I’d say that’s the issue here.
The solution’s generally to run:
lodctr /R
from an administrative command prompt. This will rebuild the counter information.
It’s unlikely this will cause any harm, but as always it’s worth taking a backup first and choosing a time when there’s nothing mission-critical happening on the machine.
If the issue persists after a rebuild please let us know and we’ll see what other possible causes there might be.
Regards,
Nick
That fixed it. Thanks
Great, glad to hear it