Ok. I think this needs an issue in GitHub.
I had some problems with master today on windows (my build). I need to bisect to find the commit that caused it.
OK, I’ll see if I can do a github issue - never done one, but I’m sure I can follow the directions! Thanks all.
Still no “luck” for me. I also tried with a blank AppData folder to exclude that my default module pipe prevents the crash. But everything’s fine so far.
Weird… I’m not using OpenCL as I don’t any decent graphics… are you?
This did the trick 
Edit
BT was empty 
Here are some with content.
darktable_bt_L5LPQ1.txt (33.1 KB)
darktable_bt_OTR2Q1.txt (33.1 KB)
darktable_bt_WLR0Q1.txt (33.1 KB)
Ha good. Sorry I didn’t think to mention my lack of openCL before…
Shall I still go ahead and post a github issue?
Oh, it’s even “working” when I set openCL profile to “Standard”. I normally have it set to “Very fast GPU”.
So,
openCL off = crash
openCL Standard = Crash
openCL Very fast GPU = Stable
At least for me
I think so.
Oh, that’s interesting too. Thanks for going to the trouble - glad it’s not just me seeing it!
@apostel338 can you describe the steps to reproduce? What’s the build number? It seems to be caused by the CPU path vs OpenCL.
We definitely need an issue in GitHub for proper tracking.
PS. This is why doing these builds and testing is important, so we can identify issues early and find a fix for them.
Pretty much the same as @123sg described.
Open a photo, going directly to exposure, making some exposure adjustments, it always crashes at the third input. But it’s not only exposure exclusive.
Crash with exposure, openCL *standard:
Crash with color balance rgb, openCL off:
As mentioned above, I also tried with blank AppData folder. A very short test showed, that it happens with NEF and ARW pretty fast, but takes longer with some old CR2 I have. Nikon and Sony crash within seconds, but I can play a minute in exposure of a CR2, and nothing happens. Switching between the modules and make adjustments makes it still crash at some point.
Work meetings, so i cant test at the moment.
Can you also do a -d perf to confirm it is the CPU path? When you select Very fast GPU, it tries to only use the GPU path and not the CPU.
Thanks for starting the Issue in GitHub. We should continue the conversation there instead of here.
I was able to reproduce turning OpenCL off. I wonder when this started since I always have OpenCL on and I’m using fedora more than windows lately.
There is a possibility that I didn’t build correctly, since I was using new instructions. I ran the build I created on the machine it was created on without problems. I ran it on a win 10 machine and it crashed every time I tried any kind of edit. I pulled the latest from today and rebuilt using my build scripts, then tested on win10 and everything seems to work fine.
Here’s the link to the new build, https://drive.google.com/file/d/1OZnPac0_NxgsINH8xkBD4_zZ85jWv6x1/view?usp=sharing. Try it and see if the problems go away.
Your new one crashes without any message, also no event in the win-protocol.
OpenCL GPU only seems still solid.
Just tried again on windows 10 and now it’s crashing with Magick: caught exception 0XC0000005 Access violation. I caught it by running darktable in a windows command prompt.
@wpferguson I posted this in GitHub
I remember that I still have a few of the .exe files from my previous builds. Ive installed them in a clean directory to see when I can get it to reproduce. So far I’ve tested 4.1.0+19, +67, +109 and no issues. At +175, it did crash. I’ve been using UCRT since +67.
I always get the Magick: …
edit:
the last commit I have that does not crash (+109) : 4ea7e5d5cc0d5e98a322a64eea62e0c7d38e6e43
the first commit I have that does crash (+175): 808361fe8bdce378dc65d2f813b0f883b090cb95
I’m at work but just recently switched to UCRT. I will try a build when I get home if you like…
Last weeks insider build 123 is fine too.
Can you get me the commit?
Sorry, me n00b. Filename says 4.1.0+123~g51460ce3e. Is this what you need?