Thanks for posting! Solved my CTD problem.
Thank you so much! I have Capture One 21 and after renaming the DLL my CTD problems are completely gone!
My CTD problems are solved now, too. Thank a lot!!! 
btw: Simply renaming the file mentioned above was not enough in my case, after disabling the explorer integration in Capture One settings the CTDs disappeared finally.
As you can read in other posts the CTD is 100% sure if you have Capture One installed (with explorer addin).
I received an update on Zen Desk:
Last 48 hours I had 0 CTD (total flight time 26 hours).
Itās important to know that you can use Capture One and FS together but you need to remove manually C1 explorer addin.
Iām not 100% convinced yet. I have and use Capture One 21, explorer integration is activated in Capture One settings, the DLL is on my system and not renamed, but I have no CTDs.
1 Like
I also have (and had all the time iām using MFS) Capture One and not a single CTD. I recently came back to try MFS and it was crashing all the time. Always around big airports (EKCH to be precise) Disabling AI traffic according to know issues thread seems to help, not a single crash since then. I didnāt touch Capture One at all.
If you donāt have CTD you can use AI, multiplayer, 100% traffic (all kind of).
If you CTDs with these options on you need to uninstall C1 addin
1 Like
After trying almost 20 other proposed solutions, the Capture One DLL rename was the thing that finally ended my CTD hell.
1 Like
Thanks for giving me back flying time in stead of troubleshooting time.
The consistent CTDās between EHAM and EHRD are gone.
2 Likes
you have an nvidia card ? The link to the CO forum I posted, also mentioned the bug report and the finger pointing is to nvidia. So may be you have a amd card ..
Intressting is also that the future linked topic: nvwgf2umx.dll crashes - [ARCHIVE] Photo beta on Windows threads - Affinity | Forum
mentioned then
nvwgf2umx.dll crashes
which we also seen sometime on forum.
1 Like
Yes.
As I have written earlier, I have the latest build (now 14.3.1) of Capture One 21 installed, and could not see the dll loaded in my flightsimulator process two days ago. I also havenāt had CTDās lately.
Unfortunately I just checked again and it is now loaded 
ā¦
Maybe the problem doesnāt exist when using the latest release, or I will run into the issue soon. Will update if thatās the case.
1 Like
Hi all,
I am very disappointed with Asobo: they tell us to remove Capture One because it prevents MSFS from running.
This is NOT TRUE.
Before WU5, there was NO PROBLEM WHATSOEVER if you had C1 and MSFS on the same computer. I flew a lot, no ctdās
The problem started when Asobo/microsoft amended the program code for use on the xbox.
ONLY THEN did the CTDās start BECAUSE MSFS LOADED THE WRONG (C1) dll.
Asobo should NOT tell us to unload C1!
Asobo should put out a hotfix wich ends the problem. I think THAT is the right way to communicate and amend.
Gert
5 Likes
This is a temporary fix
Hi GIEI,
That is right. Excellent it was found by EmmaPeel7259. I react to the Asobo communication to you.
Because they didnāt say anything about fixing. The wording of their reply to you suggests the ctdās are because of Capture One.
And THAT is not true.
Gert
Update to my earlier post:
A while ago I had a test flight which systematically CTDed.
Strangely, that went away for a while : https://forums.flightsimulator.com/t/lfmn-nice-to-lfmd-mandelieu-ctd/441529/23?u=calitfipst
So I retried it tonight and twice in a row had the CTD again, same place, same time into the flight. I checked that the Capture One dll was indeed loaded into my flightsimulator process both times.
Renamed the dll, checked it was not loaded in my process, and had the same flight without CTD. Maybe one flight is not enough to confirm this is conclusive, will continue testing when I have time.
Why it it always happens in the same place, is still a big mystery to me.
To me happens in Madrid, without C1 addin I tried 10 times and works flawlessly
Donāt want to get too excited but this appears to have been my CTD issue as well! Interesting it was never an issue until the latest updates. Amazing find sir!
Believe it. Relief at last! I discovered this fix this solution/thread this weekend. I havenāt had a single CTD since applying this fix.
Glad to see I could help so many people. Thank you for your feedback, I hope it will help to make Asobo to investigate the problem soon. At least they already confirmed that the issue is now on their bug list.
I did some more research which may be interested for those, who found the relation between Capture One and MSFS too bizarr to be true.
First, the proposed renaming of the file is just a shortcut. The codec is also registered in the windows registry ([HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{7ED96837-96F0-4812-B211-F13C24117ED3}\Instance{A0958829-3488-4adf-B95F-F4FEFC67B96E}]) as Image decoder. Removing/renaming this registry entry should have the same effect than renaming the file.
Since it is registered as āPhase One Image Decoder 2ā, I assume this is used to show raw files of Phase One cameras in the explorer. This might explain why disabling the C1 explorer integration also fixed the problem for some of you.
I can not imagine why MSFS is trying to load any image decoder at all, but since the module C:\WINDOWS\system32\windowscodecs.dll has been loaded immediatly before P1.WIC.NativeComWrapper.dll, they seem to use the Windows WIC API for some reason. Everything beyond is pure guesswork, but from a technical point of view it is more likely the the actual bug is somewhere in the Capture One image decoder. It is implemented based on Microsofts .NET framework (clr.dll is the core runtime of .NET framework), and in .NET, there is a thing called garbage collector (GC). The GC is responsible to dispose no longer used data structures and decides itself, when to call the dispose code of that data. If this code tries to access to a native ressource like a memory pointer or a windows handle which has been released by another party, you could get these access violation exception. So, we should not blame Asobo too hard for nowā¦
On the other side, if you load any third party software in your program, you have to expect it to fail and implement precautions to prevent a CTD. Especially as this problem might not be restricted to C1 and could occur with any third party image decoder, I think Asobe is still in charge to provide a fix for this error pattern.
2 Likes
Do we know the image meta being used within mfs? If so, wouldnāt it be better to change the āDefault apps by file typeā ?
When looking at the WIC API i come across IWICImagingFactory::CreateDecoder (wincodec.h) - Win32 apps | Microsoft Learn
If they create a decoder with a NULL vendor it will probably load what has been registered for that image type and performs fallback if none is registered to default MS?
Itās speculation though, someone with experience with the WIC API should i think be able to answer that question. If this is the case using the constant GUID_VendorMicrosoftBuiltIn would solve it probably. One would expect all the image types having native support.
If the above is the case, and it could be helped by asigning a different, or default, for file type. It will not break explorer integration and no register edits are needed.