https://www.displayfusion.com/Discussions/RSS/?TopicID=019f525e-ea02-7680-96ab-4748d38c1050 DisplayFusion RSS: DisplayFusion conflicting with LaunchBox/BigBox Startup Video Sun, 12 Jul 2026 17:35:57 GMT en hourly 1 https://www.displayfusion.com/Discussions/RSS/?TopicID=019f525e-ea02-7680-96ab-4748d38c1050 https://www.displayfusion.com/Discussions/View/displayfusion-conflicting-with-launchboxbigbox-startup-video/?ID=019f525e-ea02-7680-96ab-4748d38c1050 Sat, 11 Jul 2026 18:09:40 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/displayfusion-conflicting-with-launchboxbigbox-startup-video/?ID=019f525e-ea02-7680-96ab-4748d38c1050 DisplayFusion 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. ]]>