The Issue:
When launching BigBox with an intro video enabled (via a startup.mp4 file), DisplayFusion prevents the startup video window from closing or yielding to the main application interface.

The video plays perfectly through to the end, and the application is actively receiving keyboard input—pressing the spacebar successfully triggers the audible "Initializing Big Box" audio cue in the background. However, the video canvas remains visually locked on top of the screen and refuses to drop focus or close, trapping the user until forced closed via Alt + F4. If the video file is renamed or disabled, BigBox launches completely fine.

Through Task Manager troubleshooting, we discovered that BigBox spawns two separate window instances under the same process tree when playing the video.

Environment Context:

OS: Windows 11

Frontend: LaunchBox/BigBox

Launcher Path: %USERPROFILE%\LaunchBox\BigBox.exe

Core Engine Path: %USERPROFILE%\LaunchBox\Core\BigBox.exe (This is where the actual active windows/threads originate).

Everything We Have Attempted:
Global Hook Disabling (Advanced Settings):

Changed Disable Application Hooks (all applications) to True.

Changed Pause Global Hooks on Full screen to True.

Result: This successfully allowed the intro video to hand off cleanly into the BigBox main menu, proving that DisplayFusion's application hooks are directly responsible for trapping the video window layer. (These settings were reverted back to False afterward to protect global system stability).

Custom Scripted Trigger (C++ / C# Function):

Created a Window Created Trigger for the BigBox process.

Executed a scripted function designed to forcibly release/fix the focus loop the millisecond the window initialized.

Result: Did not resolve the issue; the video canvas still remained locked on top. The trigger and function have been cleanly deleted.

Targeted Compatibility Rules (Launcher Stub):

Added a rule for %USERPROFILE%\LaunchBox\BigBox.exe.

Checked: Disable TitleBar Buttons, Disable Window Snapping, and Disable Application Hooks.

Checked/Unchecked: Tested toggling Treat this as a full screen application always.

Result: No change. The video canvas still wouldn't close because the underlying engine runs from the subfolder.

Targeted Compatibility Rules (Core Engine):

Added a matching, independent rule for the true core process: %USERPROFILE%\LaunchBox\Core\BigBox.exe.

Tested combinations of the following checkboxes:

Disable TitleBar Buttons

Disable Window Snapping

Disable Application Hooks

Treat this as a full screen application never

Disable moving new windows to current monitor

Result: The video window continues to remain stuck on top, implying that DisplayFusion's hook exclusions for the main core executable are not filtering down to the secondary sub-window handle or media playback thread responsible for the overlay.

Hey Owen, sorry for my delay, got going with the work week and didn't have a chance to check back on the forum.

I just tested this exact scenario. I went into Advanced Settings and set "Disable System Hooks (applications)" to "Application hooks will be disabled" while leaving the polling hooks, shell hooks, and the "Pause Global Hooks on Full Screen" option at their default settings.

Unfortunately, it did not fix the problem. The visual trap still occurs—the intro video plays and accepts keyboard input (I can hear the menu initializing in the background), but the video canvas remains locked on top of the screen.

It seems that disabling just the application hooks globally isn't enough to release the video window layer. It appears to require the broader behavior of the full "Pause Global Hooks on Full Screen" setting to hand off cleanly. Let me know what you'd like me to isolate next!

The main website is https://launchbox-app.com/. LaunchBox itself is a free download (the standard desktop UI), while BigBox is the premium, cabinet/controller-focused frontend interface.

However, the standard free LaunchBox download actually includes a 30-minute BigBox demo mode, which should be plenty for your team to test and reproduce the startup video window-layering behavior!

Once installed, you can simply drop a video file (e.g., startup.mp4) into the LaunchBox\Videos\Startup directory to enable the intro video sequence on boot.

Alternatively, if you need a full NFR/developer license to test unrestricted builds, the Unbroken Software development team is very active on their community forums and responsive to developer inquiries.

Ah, that may explains it! I am currently on the main stable release channel.

I saw in that thread that v13.28-beta changed video playback to be handled natively inside BigBox itself rather than spawning an external/secondary process window. That makes total sense why it wasn't getting trapped in your environment!

I'm going to opt into the LaunchBox beta updates right now to test if upgrading solves the hook conflict on my end. I'll report back shortly!

Updating to the latest LaunchBox/BigBox beta fixed it completely!

Once updated, the startup video transitioned into the main menu smoothly with spacebar input, even with all default DisplayFusion global hooks and settings enabled.

Thank you so much for testing that out and pointing out the beta thread—everything is running perfectly now!