Thanks
@LucaMs (and Gemini). ChatGPT suggested the same workaround, but I'm curious as to why screen rendering continues for some applications, but does not for others, specifically my Java based B4J applications.
Incidentally I have tried the workaround by plugging in a HDMI EDID Emulator which I acquired - not exactly inexpensive - when I was tracking down another video playback on a large LED screen problem, but haven't yet found a combination of screen settings that makes that a workable solution and I'd rather not have an peripherals plugged into the remote laptop.
[Again Gemini]
Yes, there are diagnostic tools perfectly suited for your needs: they go beyond simply monitoring the list of active processes; they intercept communication at the level of system messaging and the graphical rendering flows between the operating system (Windows) and individual applications.
There are three primary tools for understanding what a window is receiving (or failing to receive) in terms of events, and why the user interface (UI) of some software freezes while others remain responsive:
1. Microsoft Spy++ (Included with Visual Studio)
This is the classic, go-to tool for this type of investigation. Unlike the Task Manager, Spy++ hooks directly into the Windows window management system.
How to use it: Launch Spy++, use the "Find Window" tool (the crosshair icon) to select your B4J application window, and open the "Log Messages" view.
What it shows in real time: It allows you to see every single message that Windows sends (or fails to send) to the window—such as WM_PAINT (the command for graphical redrawing), WM_MOUSEMOVE, WM_LBUTTONDOWN, WM_SETFOCUS, etc.
Why it’s useful in your case: If you close your laptop lid and connect via DWService, you can observe whether WM_PAINT messages and input events are actually reaching the JavaFX window's message queue, or if the operating system has stopped sending them due to power management settings affecting the virtual display.
2. WinSpy++ or Inspect.exe (Windows SDK)
These tools analyze the window tree (Window Handles – HWND) and allow you to inspect the internal properties of individual UI controls.
Inspect.exe (provided with the Windows SDK) displays the accessibility and UI Automation (UIA) hierarchy. This allows you to verify whether your app's graphical components (such as text areas or text fields) are still enabled, visible, and have active system focus, or if the accessibility layer considers them "off-screen" or non-interactive due to the absence of an active graphical surface.
3. JavaFX Event Viewers/Tracing (Prism Logging)
Since we are dealing with a B4J application (which runs on the JavaFX engine), the bottleneck is not so much Win32 itself, but rather how the underlying graphics engine—Prism, JavaFX’s rendering subsystem—manages the video pipeline (via Direct3D or OpenGL) when no physical monitor is connected.
You can prompt JavaFX to provide diagnostic output by launching the application from the command line with specific debug flags related to graphical rendering:
-Dprism.verbose=true (prints detailed information to the console regarding which graphics pipeline is being used—e.g., Direct3D 9/11 or software rendering).
-Dprism.forceGPU=false, or forcing software rendering (-Dprism.order=sw), can help determine whether the JavaFX engine stalls while waiting for a hardware VSync signal—a likely scenario when a physical GPU is unavailable due to the laptop lid being closed.
In summary: what approach should you take?
If you want to immediately verify whether the issue lies in the receipt of input or drawing messages, Spy++ is the ideal listener; it will tell you right away whether mouse clicks sent via DWService are being translated into Windows messages directed at the application, or if they are being "lost" before they ever reach the window.
