Code relying on flist() was acting inappropriately in Windows.
BYOND Version:514
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 96.0.4664.110
Applies to:Dream Daemon
Status: Resolved (514.1578)

This issue has been resolved.
Descriptive Problem Summary:
Dream Daemon freezes upon attempting to launch a project.
Numbered Steps to Reproduce Problem:
1. Build project
2. Attempt to launch it with Dream Daemon
3. Dream Daemon freezes and sits there consuming around 30% CPU forever

Project is SS13 Goonstation master branch

Expected Results:
It launches

Actual Results:
It freezes

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
Problem present in patch 514.1577, does not occur in 514.1575

Use version 514.1575
Try compiling in 1575 and running in 1577. If that's fine then it indicates a compiler error. I don't think anything changed regarding the server code so I assume this has to be related to compilation.

Can you give me a link to the exact repo? Like a specific build, not just the current status of it? I'll also need to be able to compile it as-is without having to build any intermediate stuff. If you don't have that set up, I suggest getting a .zip together with source that can be compiled from scratch and I'll give that a shot. Chances are I'll discover something in compilation.
I found a separate bug where global vars with strings didn't compile right, which is basically another version of the issue with static vars but it's a case I didn't catch. It would not explain a hang, but if your project is stalling due to trying to contact an SQL server or something that might be an issue.

The codebase I just retested compilation for had some SQL info in global vars, and it didn't compile those in correctly. With that resolved, the only issue I'm seeing in compilation is that some strings that would ordinarily be used in a pointless ASSERT() aren't compiling into the .dmb. The game is not hanging on load, but of course it's a different codebase.
Thanks for the swift response, compiling in 1575 and running in 1577 does not work, it still hangs. I'll link you to my fork of the repository so we can guarantee no new commits: master
The build process is here though that probably isn't what you mean by compiling as-is unfortunately.
I'm not sure how to check what exactly it's hanging over, since it doesn't even get to the point where our logging system starts.
Yeah, I'm gonna need a .zip with code that I can just compile directly, without going through a whole pre-build process. If you can run the build process to set up the source in that state, I can try to take a look.

However another important caveat is that if there are any external .dll files needed, I can't test the hang, but only the compilation. I suspect the compilation issue I discovered may be a factor here but ultimately I need a way to test the hang. I suspect that external .dlls aren't needed for that to happen, so if you are using those then you'll need to set up a version that doesn't rely on them. 1otxn3PmCoK56Ygkvd6rmy8MMBjs6CAFq/view
I've gutted out all DLL references I could find, and this seems to compile fine straight from dream maker.
Lummox JR resolved issue with message:
Code relying on flist() was acting inappropriately in Windows.