Any way to speed up Launchbox startup?

[stigzler]

I've followed the guide here:

https://feedback.launchbox.gg/en/help/articles/9454889-troubleshooting-launchbox-and-big-box-performance

but LB startup is still taking around 15 seconds if launched vanilla. That might be OK for normal use, but it makes plugin development really slow given compile + launch time for debugging (think it's even slower when debugger is attached). 

I'm wondering whether it's my development installation as if I turn on the debug log, there are loads of exceptions during LB initialisation (attached). I note there are a load of unresolved assemblies which do seem to take time according to the timestamp. 

Any help appreciated. 

Debug 2025-12-27 03-03-09 PM.log

Edited December 27, 2025 by stigzler

[JoeViking245]

1 hour ago, stigzler said:

there are loads of exceptions during LB initialisation

"Microsoft.DotNet.DesignTools.Server" related error.  Never seen this one before. Are your plugins (or one or more you have installed) using WinForms instead of WPF?  It looks like that is what this is relating to. Maybe the version being used is not compatible with .NET 9?  No idea, really.

"Unable to read data from the transport connection".  I consider that to be "just a thing".  Only because I don't know what exactly is, and doesn't appear to actually cause issues. Functionally or performance wise. (and it always shows)

 

I recently [finally] replaced my 16-year-old antique PC (i7 something, 8GB RAM, video card not-worth-mentioning and a 13yo HDD)  to an i5 14400F, RTX5060 8GB, 16GB RAM and an NVMe SSD.  Both Visual Studio and LB are on SSD's.  Debugging startup time went from close-to-a-minute+ to 15ish seconds.

[SiriusVI]

"Unable to read data from the transport connection"

I get this error message multiple times in my logs every time I close Launchbox. Seems to be a more common error. 

[stigzler]

Hi @JoeViking245,

Thanks for the response.

On 12/27/2025 at 4:42 PM, JoeViking245 said:

"Microsoft.DotNet.DesignTools.Server" related error.  Never seen this one before. Are your plugins (or one or more you have installed) using WinForms instead of WPF?  It looks like that is what this is relating to. Maybe the version being used is not compatible with .NET 9?  No idea, really.

Yes - one does use winforms, but I couldn't find a reference to Microsoft.DotNet.DesignTools.Server anywhere in it and also using .net 9 (as do all dependency libs). I also followed some of your previous advice and downloaded it and put it in the "ThrirdParty" folder. Still no dice on alleviating the error. Extracts from a repeat run today (28 seconds to compile and run):

2026-01-02 11:17:45 AM Game.PlayTime changed from 0 to 41: HAVOC (Players Premier) (Games)

2026-01-02 11:17:49 AM Resolving assembly Microsoft.DotNet.DesignTools.Server, Version=1.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35...
Could not load file or assembly 'Microsoft.DotNet.DesignTools.Server, Version=1.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.
   at System.Reflection.RuntimeModule.GetDefinedTypes()
   at System.Reflection.RuntimeModule.GetTypes()
   at Unbroken.LaunchBox.Windows.Root.LoadProcContainer[T](IEnumerable`1 param, ConcurrentDictionary`2& vis)
{other instances of this error}
2026-01-02 11:17:49 AM EXCEPTION IGNORED: Unable to load one or more of the requested types.
Could not load file or assembly 'Microsoft.DotNet.DesignTools.Server, Version=1.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.
   at System.Reflection.RuntimeModule.GetDefinedTypes()
   at System.Reflection.RuntimeModule.GetTypes()
   at Unbroken.LaunchBox.Windows.Root.LoadProcContainer[T](IEnumerable`1 param, ConcurrentDictionary`2& vis)

2026-01-02 11:17:51 AM FIRST CHANCE EXCEPTION: C:\Users\stigz\LaunchBoxDevelopmentInstall\pack:\application:,,,\WpfResources\Background.png
   at System.Drawing.Image.FromFile(String filename, Boolean useEmbeddedColorManagement)
2026-01-02 11:17:52 AM Resolving assembly Presentation.resources, Version=0.8.18.576, Culture=en-US, PublicKeyToken=null...

I do note, however, that the error instances only occur in the same second (49s). I'm not sure form the log if the line at 11:17:51 is related to the above error or not (not discernible from the log). Also, I note 4 seconds between 11:17:45 and 11:17:49 which appear to have no log entries in so again, not sure if the Microsoft.DotNet.DesignTools.Server error is related to this or not?

In short it's really difficult to pinpoint the origins of this and indeed whether it is this that is causing the startup delays. It's really hard to get any pointers form the log. Doubt there's much you can do or advise, mind. 

On 12/28/2025 at 8:38 PM, SiriusVI said:

I recently [finally] replaced my 16-year-old antique PC (i7 something, 8GB RAM, video card not-worth-mentioning and a 13yo HDD)  to an i5 14400F, RTX5060 8GB, 16GB RAM and an NVMe SSD.  Both Visual Studio and LB are on SSD's.  Debugging startup time went from close-to-a-minute+ to 15ish seconds.

Ryzen2700X, 32 GB DDR4 Ram, VS and LB on NVME ssd. All other drives ssds. Doubt it's my computer. 

Launch times:

Via exe: 16.44s

Via VS Debug + Compile: 28s

It'd be helpful to know if these kind of times are standard for LB so I can stop looking for anything in my code that's causing slowdowns in compile times. No issue if it is of course, just helpful to know. you did mention 15 seconds - is that via the exe?

Debug 2026-01-02 11-17-42 AM.log

Edited Friday at 11:45 AM by stigzler

[JoeViking245]

1 hour ago, stigzler said:

it's really difficult to pinpoint the origins of this and indeed whether it is this that is causing the startup delays.

When you launch from just the exe, does the DesignTools error appear? 

If yes, if you remove your plugin from the mix (I usually just rename the plugin file to MyPlugin.dll.joe so it doesn't load) and launch from the exe, does the error still appear?

Keep doing the same with other 3rd party plugins until you "find the culprit".  (3rd party ones, not the LB emulator integration ones)

 

A quick check just now on my [relatively] stripped-down version of LB, I had (approx.) 13s from the exe and about 20s from VS.  But also the plugin I loaded via VS was a tiny 22kb file (not a whole lot to it) and there were no changes so essentially already compiled.

You are testing through LaunchBox and not Big Box. Correct?

[stigzler]

Thanks again, Joe. Appreciate your help. Yeah - moving my plugin's folder out of the Plugins folder removed the error. Weirdly, renaming the 'entry point' dll (ie. the one that contains ISystemEventsPlugin etc) did not. However, as stated above, I'm not even sure how long a delay this takes (could even be within one second from logs). 

Whichever way, along with your start-up times which are really helpful, I'm just going to have to suck it up, I think. Nemmind.

EDIT: Just started it via exe without any of my plugins in: 17 seconds. I don't think it's my plugin (despite the missing ref error) - likely just the normal startup time).

Edited Friday at 03:42 PM by stigzler

[Jayinem]

By startup do you mean just running it yourself or upon Windows boot? 

 

On Windows boot I put it in task scheduler and it was up within 7-8 seconds of WIndows booting. 

[stigzler]

4 minutes ago, Jayinem said:

By startup do you mean just running it yourself or upon Windows boot? 

 

On Windows boot I put it in task scheduler and it was up within 7-8 seconds of WIndows booting. 

Running 'myself' - i.e. via exe double click or VS debug. 

[Jayinem]

Well the way I do it is run it at boot and use autohotkey scripts to make sure it never closes or even minimizes, and if it does either it comes right back up on it's own. I consider my Launchbox my "desktop wallpaper" always fullscreen always on. However if I want to use firefox or any other app it goes in front of it without any issue. It's pretty awesome I think. I could give you those autohotkey scripts to use if you want. 

[stigzler]

36 minutes ago, Jayinem said:

Well the way I do it is run it at boot and use autohotkey scripts to make sure it never closes or even minimizes, and if it does either it comes right back up on it's own. I consider my Launchbox my "desktop wallpaper" always fullscreen always on. However if I want to use firefox or any other app it goes in front of it without any issue. It's pretty awesome I think. I could give you those autohotkey scripts to use if you want. 

Thanks fella, but doesn't really fit my use case. Nice setup though. 👍