Created attachment 131826 [details] kritalcmsengine.dll crash log There has been multiple report of Krita crashes at launch on a specific laptop: Lenovo Legion Y7000P (2019). The kritacrash.log file revealed it to be caused by kritalcmsengine.dll. One of the reporters appeared to be a very experienced IT engineer. He cooperated in a thorough troubleshoot that exhausted all my knowledge with no success. According to his report, the same machine was able to run Krita until he had to reinstall Windows 10 because his kid broke the system. It is now running the latest Windows 10 2004, with all the updates and newest drivers installed. The machine might have some peculiar hardware/software configurations. It has a NVIDIA GTX1660 GPU, the system listed 2 displays, with identical device name: Lenovo Display 1920x1080 (It has a specific driver). I suspect one of them is connected to Intel integrated GPU. I instructed him to change the display driver to Generic PNP Display, but it didn't work. In Windows 10's Color Management dialogue, only one display was listed, and it has 3 ICM/ICC profiles attached. I instructed him to delete them and uncheck "use my settings for this device", which didn't work either. We also repeat the same procedure on System-wide settings, didn't work either. For some reason, on Advanced tab of Windows Color Management dialogue, it was using Relative Colormetric. I instructed him to changed it back to System Default, it didn't work. At that point, I exhausted all possible workarounds and decided to make this report.
This should be fixed in Krita 4.4, tiar did a lot of checks here. What is going on is that the Lenovo icm/icc profiles are ALL malformed (telling us there's info that ISN'T there), so we had to input more checks.
*** This bug has been marked as a duplicate of bug 423685 ***
Created attachment 131827 [details] Windows Color Management ICM profiles
(In reply to wolthera from comment #1) > This should be fixed in Krita 4.4, tiar did a lot of checks here. > > What is going on is that the Lenovo icm/icc profiles are ALL malformed > (telling us there's info that ISN'T there), so we had to input more checks. Krita 4.4 alpha didn't work for the reporter.
Weird... I've tested with a bunch of lenovo profiles, and couldn't get any crashes anymore. If this is the case, we need the contents of the profiles folder to test with. c:\windows\System32/Spool/Drivers/Color/ is where they should be.
(In reply to Boudewijn Rempt from comment #5) > Weird... I've tested with a bunch of lenovo profiles, and couldn't get any > crashes anymore. If this is the case, we need the contents of the profiles > folder to test with. c:\windows\System32/Spool/Drivers/Color/ is where they > should be. OK, I will try to contact him, or I can get those from Lenovo's support website. I will get back to you when I have those.
Best get the actual contents of that folder on his system.
Created attachment 131829 [details] the file handed by reporter
That's curious, because both Krita 4.3.0 and a few other builds later: 8d98437 ccbadb2 (June 29) in fact crashes, all the newer ones since 2e38c26 (August 22) do work just fine on my system with those profiles in the resource folder. I've made two commits, on 21 August and 25 August, so all builds downloaded after let's say August 26th should be fine. @Tyson can you please confirm that the version the reporter is using is recent enough to have those changes in?
Created attachment 131831 [details] Display driver extracted from Y7000P 2020H For some reason, the extracted driver was kept inside a DolbyVision directory. It contains multiple ICM files.
Damn... I removed the previous broken profiles and added those and I still get the same results: crashes on 4.3.0, doesn't crash on recent enough 4.4.0 alpha. Someone else needs to check this report as well, I guess. (My comment 9 is about profiles in comment 8, and this comment is about profiles in comment 10).
(Note: I'm testing on Linux; however the previous crashes in LcmsColorProfileContainer::init were also present on Linux after doing the following steps to reproduce: 1. Create directory "profiles" in the resource folder. 2. Put profiles inside. 3. Open Krita. I can reproduce the crash on 4.3.0., but cannot on 4.4.0 alpha) Also another note: I believe the files from DolbyVision are also present in the previous zip archive, at least names are the same.
None of the profiles inside the dolbyvision folder crash on master for me. (Some don't get loaded, but that's it)
Maybe you should test it by running the Setup.cmd file under Windows 10...I never saw any driver assigned more than a single ICM file -- this one however, assigns 7 ICM files via the INF file. I think it might have confused Krita's CMS module in some way. Maybe the crash wasn't just caused by A faulty ICM file, but how multiple ICM files got assigned to Windows Color Management, including the faulty ones.
Krita doesn't read any INF files, we just try to load every icc and icm file in the Color folder.
I wonder how does Krita's logic operate when the "Use system monitor profile" option is checked, if the display driver has multiple ICM profile assigned? Is it possible that those ICM files are HDR related?
On windows, that isn't used (yet) -- we have no integration for that.
The reporter said he found out that it was Windows Defender that blocked Krita from launching. He was able to run Krita again by using the portable version.
I'd still keep it as duplicate because the profiles do crash the affected version of Krita. Good that it's solved for them now!
The reporter said 4.4 alpha actually worked for him, he made a mistake by deleting the wrong files. I guess this bug is indeed a duplicate.
Okay, thanks for confirming that!