[GH-ISSUE #633] Crash with new recorder UI on 3+ monitor setup. #517

Closed
opened 2026-02-26 09:31:44 +03:00 by kerem · 12 comments
Owner

Originally created by @waltdestler on GitHub (Apr 8, 2020).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/633

ScreenToGif is crashing on my computer if I try to use the new recorder UI with at least 3 monitors enabled in control panel. (By "crash" I mean that after clicking "Recorder", the startup window disappears, it thinks for a second while my mouse cursor moves very slowly, and then it silently exits without any error message.) If I disable any combination of monitors such that I have at most only 2 active, then it works fine. FWIW each of my monitors has a different DPI scaling setting, but I tried setting them all to 100% with no luck.

I also tried building from source and running with the Visual Studio debugger attached, but the same thing happens: the process simply exits without any obvious error or exception thrown. I tried manually stepping through with the OpenRecorder command in ApplicationViewModel.cs, but stepped through it fine; it quits someplace later that I wasn't able to determine.

I'm a programmer myself and know C# very well (though I have little experience with XAML), so I'm happy to help try to debug this, I just need a tip on where in the code I should try looking for an issue.

OS: Windows 10 x64 10.0.18362

Originally created by @waltdestler on GitHub (Apr 8, 2020). Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/633 ScreenToGif is crashing on my computer if I try to use the new recorder UI with at least 3 monitors enabled in control panel. (By "crash" I mean that after clicking "Recorder", the startup window disappears, it thinks for a second while my mouse cursor moves very slowly, and then it silently exits without any error message.) If I disable any combination of monitors such that I have at most only 2 active, then it works fine. FWIW each of my monitors has a different DPI scaling setting, but I tried setting them all to 100% with no luck. I also tried building from source and running with the Visual Studio debugger attached, but the same thing happens: the process simply exits without any obvious error or exception thrown. I tried manually stepping through with the `OpenRecorder` command in ApplicationViewModel.cs, but stepped through it fine; it quits someplace later that I wasn't able to determine. I'm a programmer myself and know C# very well (though I have little experience with XAML), so I'm happy to help try to debug this, I just need a tip on where in the code I should try looking for an issue. OS: Windows 10 x64 10.0.18362
kerem 2026-02-26 09:31:44 +03:00
Author
Owner

@NickeManarin commented on GitHub (Apr 9, 2020):

Hi, you can try running and crashing again, open the Event Viewer (Windows X > Event Viewer) and check for any errors on the Windows Logs > Application section.

Uncaught errors should appear in there in two items on the list.

Also, it's possible that the app created some logs in the same folder as the main executable, (actually, in a folder called ScreenToGif/Logs inside the same folder of the executable).

<!-- gh-comment-id:611543284 --> @NickeManarin commented on GitHub (Apr 9, 2020): Hi, you can try running and crashing again, open the Event Viewer (`Windows X > Event Viewer`) and check for any errors on the `Windows Logs > Application` section. Uncaught errors should appear in there in two items on the list. Also, it's possible that the app created some logs in the same folder as the main executable, (actually, in a folder called ScreenToGif/Logs inside the same folder of the executable).
Author
Owner

@waltdestler commented on GitHub (Apr 9, 2020):

Nothing in ScreenToGif/Logs, but I do have a couple errors in the Windows event viewer:

Application: ScreenToGif.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: exception code c0000005, exception address 00007FF84D3A2E14

Faulting application name: ScreenToGif.exe, version: 2.23.0.0, time stamp: 0x5e8cf186
Faulting module name: wpfgfx_v0400.dll, version: 4.8.4121.0, time stamp: 0x5deb3768
Exception code: 0xc0000005
Fault offset: 0x00000000000e2e14
Faulting process id: 0x9eb8
Faulting application start time: 0x01d60e7a9650a57a
Faulting application path: C:\Program Files (x86)\ScreenToGif\ScreenToGif.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\WPF\wpfgfx_v0400.dll
Report Id: 60ea23e1-87a5-41df-86eb-95cc91356782
Faulting package full name: 
Faulting package-relative application ID: 
<!-- gh-comment-id:611557820 --> @waltdestler commented on GitHub (Apr 9, 2020): Nothing in ScreenToGif/Logs, but I do have a couple errors in the Windows event viewer: ``` Application: ScreenToGif.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: exception code c0000005, exception address 00007FF84D3A2E14 ``` ---- ``` Faulting application name: ScreenToGif.exe, version: 2.23.0.0, time stamp: 0x5e8cf186 Faulting module name: wpfgfx_v0400.dll, version: 4.8.4121.0, time stamp: 0x5deb3768 Exception code: 0xc0000005 Fault offset: 0x00000000000e2e14 Faulting process id: 0x9eb8 Faulting application start time: 0x01d60e7a9650a57a Faulting application path: C:\Program Files (x86)\ScreenToGif\ScreenToGif.exe Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\WPF\wpfgfx_v0400.dll Report Id: 60ea23e1-87a5-41df-86eb-95cc91356782 Faulting package full name: Faulting package-relative application ID: ```
Author
Owner

@NickeManarin commented on GitHub (Apr 9, 2020):

Have you found anything else? Usually it's two entries.

Anyway, so far I found that a similar crash had a missing DLL. It could be the same case as yours:

D3DCompiler_47.dll should be in %windir%\system32

But, of course, it could be something else.

<!-- gh-comment-id:611561773 --> @NickeManarin commented on GitHub (Apr 9, 2020): Have you found anything else? Usually it's two entries. Anyway, so far I found that a similar crash had a missing DLL. It could be the same case as yours: D3DCompiler_47.dll should be in %windir%\system32 But, of course, it could be something else.
Author
Owner

@waltdestler commented on GitHub (Apr 9, 2020):

Those are the two entries. (Added a line to separate them.)

I do have D3DCompiler_47.dll in my System32 directory. I also just tried copying it into the ScreenToGif folder alongside the exe, which didn't help.

FWIW, the same problem occurs regardless of whether I have it set to DirectX or BitBlt mode. (And works fine with the old recorder UI even in DirectX mode.)

Regardless, it seems pretty strange to me that a missing DLL would only be a problem with 3+ monitors... but I suppose you never know!

<!-- gh-comment-id:611631779 --> @waltdestler commented on GitHub (Apr 9, 2020): Those are the two entries. (Added a line to separate them.) I do have D3DCompiler_47.dll in my System32 directory. I also just tried copying it into the ScreenToGif folder alongside the exe, which didn't help. FWIW, the same problem occurs regardless of whether I have it set to DirectX or BitBlt mode. (And works fine with the old recorder UI even in DirectX mode.) Regardless, it seems pretty strange to me that a missing DLL would only be a problem with 3+ monitors... but I suppose you never know!
Author
Owner

@NickeManarin commented on GitHub (Apr 9, 2020):

Those are the two entries. (Added a line to separate them.)

Ah, thought it was a single one.

FWIW, the same problem occurs regardless of whether I have it set to DirectX or BitBlt mode. (And works fine with the old recorder UI even in DirectX mode.)

I believe it's related to how the new UI operates. It works as a single, full-size transparent window that fills up the entire set of screens. I don't have three monitors so I could test (I only have two).

Anyway, if is that the case, I'm already working on a new solution that does not involve creating a massive fullsize transparent window, but I'm facing some issues working with multiple DPI right now.

Regardless, it seems pretty strange to me that a missing DLL would only be a problem with 3+ monitors... but I suppose you never know!

It was the only crash related to wpfgfx_v0400.dl that I could find with a proper solution. It could be something different.

<!-- gh-comment-id:611662183 --> @NickeManarin commented on GitHub (Apr 9, 2020): > Those are the two entries. (Added a line to separate them.) Ah, thought it was a single one. > FWIW, the same problem occurs regardless of whether I have it set to DirectX or BitBlt mode. (And works fine with the old recorder UI even in DirectX mode.) I believe it's related to how the new UI operates. It works as a single, full-size transparent window that fills up the entire set of screens. I don't have three monitors so I could test (I only have two). Anyway, if is that the case, I'm already working on a new solution that does not involve creating a massive fullsize transparent window, but I'm facing some issues working with multiple DPI right now. > Regardless, it seems pretty strange to me that a missing DLL would only be a problem with 3+ monitors... but I suppose you never know! It was the only crash related to `wpfgfx_v0400.dl` that I could find with a proper solution. It could be something different.
Author
Owner

@waltdestler commented on GitHub (Apr 9, 2020):

Anyway, if is that the case, I'm already working on a new solution that does not involve creating a massive fullsize transparent window, but I'm facing some issues working with multiple DPI right now.

Ah, very cool! Feel free to ping me if you want me to test on my setup.

<!-- gh-comment-id:611676164 --> @waltdestler commented on GitHub (Apr 9, 2020): > Anyway, if is that the case, I'm already working on a new solution that does not involve creating a massive fullsize transparent window, but I'm facing some issues working with multiple DPI right now. Ah, very cool! Feel free to ping me if you want me to test on my setup.
Author
Owner

@NickeManarin commented on GitHub (Apr 10, 2020):

Ah, very cool! Feel free to ping me if you want me to test on my setup.

If you have the source there with you, you could replace the line 77 with line 78 to try opening the new version of the recorder.

https://github.com/NickeManarin/ScreenToGif/blob/master/ScreenToGif/Model/ApplicationViewModel.cs#L77

It should open normally and you should be able to select your recording region, but you won't be able to record anything, because it's not yet finished.

<!-- gh-comment-id:612031820 --> @NickeManarin commented on GitHub (Apr 10, 2020): > Ah, very cool! Feel free to ping me if you want me to test on my setup. If you have the source there with you, you could replace the line 77 with line 78 to try opening the new version of the recorder. https://github.com/NickeManarin/ScreenToGif/blob/master/ScreenToGif/Model/ApplicationViewModel.cs#L77 It should open normally and you should be able to select your recording region, but you won't be able to record anything, because it's not yet finished.
Author
Owner

@waltdestler commented on GitHub (Apr 10, 2020):

It works! It opens fine, and I can select a region, though the framerate while doing so is very low (but still usable). It does not seem to remember the region I previously selected when opening it again. (Guessing that's not implemented yet either.)

<!-- gh-comment-id:612049997 --> @waltdestler commented on GitHub (Apr 10, 2020): It works! It opens fine, and I can select a region, though the framerate while doing so is very low (but still usable). It does not seem to remember the region I previously selected when opening it again. (Guessing that's not implemented yet either.)
Author
Owner

@NickeManarin commented on GitHub (Apr 10, 2020):

It works! It opens fine, and I can select a region,

Nice!

though the framerate while doing so is very low (but still usable).

Is it the same slowness on all monitors? I noticed that the current version gets slow while having more than one monitor, but I could not improve much the performance.

It does not seem to remember the region I previously selected when opening it again. (Guessing that's not implemented yet either.)

Yeah, only the basic stuff was ported to this new version. I was working recently on the window selection when I hit a bump trying to solve the problem with multi DPI screens.

<!-- gh-comment-id:612055163 --> @NickeManarin commented on GitHub (Apr 10, 2020): > It works! It opens fine, and I can select a region, Nice! > though the framerate while doing so is very low (but still usable). Is it the same slowness on all monitors? I noticed that the current version gets slow while having more than one monitor, but I could not improve much the performance. > It does not seem to remember the region I previously selected when opening it again. (Guessing that's not implemented yet either.) Yeah, only the basic stuff was ported to this new version. I was working recently on the window selection when I hit a bump trying to solve the problem with multi DPI screens.
Author
Owner

@waltdestler commented on GitHub (Apr 10, 2020):

Is it the same slowness on all monitors? I noticed that the current version gets slow while having more than one monitor, but I could not improve much the performance.

Yes, it's slow on all monitors.

<!-- gh-comment-id:612079085 --> @waltdestler commented on GitHub (Apr 10, 2020): > Is it the same slowness on all monitors? I noticed that the current version gets slow while having more than one monitor, but I could not improve much the performance. Yes, it's slow on all monitors.
Author
Owner

@kaestlyn commented on GitHub (Jun 11, 2020):

I just want to add that I had this same issue with 3 monitors. Soon as I disconnected one, I was able to launch the app and switch back to the classic recording UI and then reconnect the monitor and the application works as expected.

<!-- gh-comment-id:642761737 --> @kaestlyn commented on GitHub (Jun 11, 2020): I just want to add that I had this same issue with 3 monitors. Soon as I disconnected one, I was able to launch the app and switch back to the classic recording UI and then reconnect the monitor and the application works as expected.
Author
Owner

@NickeManarin commented on GitHub (Aug 16, 2020):

The recorder was fully reworked.
I also disabled by default the marching-ants animation that could cause slowdowns during the selection mode (but it can be turned back in).

<!-- gh-comment-id:674476226 --> @NickeManarin commented on GitHub (Aug 16, 2020): The recorder was fully reworked. I also disabled by default the marching-ants animation that could cause slowdowns during the selection mode (but it can be turned back in).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/ScreenToGif#517
No description provided.