Hang on Windows creating new documents - deep analysis and solution, bugfix for Affinity engineers

[Michael Labbe]

Long-time Affinity user here.  I recently booted Affinity Photo 2.6.2 on a 32-core Windows PC with a 3080 and 128GB of RAM to find that, while it booted fine, it hung creating a new document of any size, including 1px by 1px.  Worse, all of Windows ground to a halt with a choppy mouse and even Task Manager taking a long time (seconds!) to respond to basic clicks.  This all happened after a full config reset.  Fortunately, in addition to being an Affinity user I'm a consultant who deals with systems performance and stability issues.  So I did an analysis (skip to the bottom for the solution).

I fired up an ETW trace and saw pretty quickly that the machine had only 6% CPU usage, no real VRAM and 14GB of RAM in use during the hang.  So, this wasn't a resource stall.  We weren't swapping memory.

Nevertheless, I dug into the hot path in photo.exe, which led to this:

We are spending 6 seconds querying the display config on Windows, and it is being called thousands of times.  That is odd.

Turns out I had a secondary HDMI 2.1 display that was connected to my 3080, but disabled in Windows.  (It was off).

The fix / workaround: unplugging the display from the video card.

Affinity engineers should take a look at their QueryDisplayConfig call path.  If they are calling QueryDisplayConfig during document initialization, especially with QDC_ALL_PATHS, it is an expensive call.  Likely, Windows is locking and waiting for the HDMI to see if it responds.

Contact me if I can be of assistance.

Mike

 

 

[NathanC]

Hi @Michael Labbe welcome to the forums,

Thanks for sharing a detailed account of the issue and workaround. We're currently investigating an issue internally relating to devices running the Windows 24H2 update intermittently causing system freezes/lockouts while working in the apps on certain user devices, as referenced in the forum thread below. At this stage, I'd like to confirm if the issue you've experienced is in any way related to this ongoing issue or if this is a separate case, and also get a device setup to confirm if this can be replicated. I've therefore got a few follow-up queries/requests below:

• What Windows Version (and build no.) are you using?
• Was 'Hardware Acceleration' enabled in Photo 2 at the time of the system hang? If you disable this in Edit -> Settings -> Performance and then repeat this test again, does the same hang occur?
• In this scenario, were both displays using a HDMI 2.1 input, and the secondary display was simply physically turned off?
• Can you provide a copy of the app log.txt file? (see thread below)

Many thanks

[Michael Labbe]

What I reported happens regardless of hardware acceleration or OpenCL settings.  It's about display initialization, not hardware acceleration.  It's not the same issue as what you linked below, as it does not crash.  It slows the entire system down indefinity, as stated.

I'm running Windows 10 22H2 build 19045.

In the scenario, the disabled display was HDMI 2.1, but the active display was DisplayPort. 

The disabled display was not physically turned off: it was using a different input source from a separate computer.  This should be the same as turning it off.

Log contains personal info - not attached to public forum.

 

Again, based on my trace, this is very likely related to QueryDisplayConfig being called by photo.exe in a very slow path, such as with the QDC_ALL_PATHS flag, which is very discouraged in production applications.

[NathanC]

Thanks for providing those details, I just needed to rule out any possibility that the two were connected.

We've created a similar setup using DisplayPort for the primary display and HDMI 2.1 for the secondary, with the secondary also plugged into a Mac (via HDMI) set as the active input source, but we didn't experience any of the described windows hangs- document creation in Affinity was instantaneous and Windows remained fully responsive. As you say- it shouldn't make a difference if the display was turned off or connected to a different input source- the EDID is persistent so the display remains visible in Windows.

There are local environment variables (Displays, GPU, GPU driver, Winver) which may account for why this hasn't been reproducible so far. If you could supply a copy of your log.txt to the private upload link below, confirm your display models and provide a screenshot of your Windows display settings we'll see if we can more closely match your setup and try duplicating this again.

https://www.dropbox.com/request/Oo1xkcDUBTScBrXljOzB

I wouldn't be able to comment on what calls should be made in this scenario, as that would be up to the developers, but before logging anything internally we need to confirm your issue can be re-produced.

[drumsdrumsdrums]

Just replying to say you're definitely onto something. I had exactly the same type of error when attempting to open files and exactly the same set up (an additional monitor connected via HDMI but currently switched off). Lo and behold, unplugging the HDMI cable allowed it to open without issue.

[Bound by Beans]

By my troth, this grows more interesting by the moment.