Studio uses 90-100% of CPU for a few minutes during startup before login

This happens every time I open Studio with or without any place and before any plugins are loaded.
It first occurred in version 0.581.0.5810563 on 2023-06-22 and still occurs in version 0.582.1.5820387.

Studio will tie up all of the system resources for so long that it fails to connect to the network, thinks it’s offline and offers to continue in offline mode or “fails to acquire an access token” according to the logs.

Logs: https://devforum.roblox.com/t/logs-studio-uses-90-100-of-cpu-for-a-few-minutes-during-startup-before-login/2445740

The workaround is to open Sysinternals Process Explorer before opening Studio.
Immediately after RobloxStudioBeta shows up, view its threads and wait for the two threads with 50% CPU usage to appear.
Suspend one or both of them until Studio logs in, then unsuspend them soon afterward.
This reduces startup time from minutes or an eternity to a dozen seconds.

Here are my specs:

Windows 8.1
Intel Celeron CPU 1000M @ 1.80GHz, 2 cores/threads
Intel HD integrated graphics
8.0GB DDR3 memory

Edit after approval:

  • Studio manages to power through and login after roughly two minutes of this if the workaround isn’t applied.
  • I don’t get this issue when I open and close places, only when opening a new instance of Studio.
  • I suspend either of the ucrtbase.DLL!configthreadlocale+0x50 threads as seen in the screenshot when they get 50% CPU. When either one is suspended, both will go dormant and allow Studio to proceed. Still on version 0.582.1.5820387 (64bit), the latest available.
  • This report is a duplicate of: High CPU utilization in Studio on the login screen


Not sure if these stacks are even useful in any way, but they might help find the right thread on a beefier machine that doesn’t 100% out from this.

1 Like

I’ve reinstalled Studio (to chase away a consistent crash-to-desktop bug that only appears to affect me) and startup time is now 30-45 seconds, which is a lot more manageable. I still apply the workaround, which fortunately was not the cause of the crashes.

Thanks for the detailed report! As noted in the other ticket we’ll deal with it there and close this as duplicate.

1 Like