Error in Windows 10 Build 14376

Ditto: I am getting the same issue with the latest build of Windows 10, Build 14376 and have also reported it to Microsoft via the Feedback Hub.

Again, Ditto: 14379 also does not particularly like DirOpus 11.19.

Sigh.

You need to tell Microsoft, not us. You're beta testing Windows for this very reason.

We have done some investigation, which is possible now that there seem to be debug symbols for the Windows build. As far as we can tell, Windows itself is creating a thread, which then calls some eventing APIs which we do not use anywhere in our code, which then callback into some random memory, causing a crash.


The top line there isn't even a valid address to code within opus7zip.dll since our debug symbols are not mapping it to anything.

If I had to guess, Microsoft have enabled extra telemetry in this Windows build, and they have a bug in their code which is corrupting a table of callback functions, making the telemetry trigger random code/memory addresses (a random address inside opus7zip.dll in the case above, but I imagine it will be other DLLs in other situations, depending on the memory layout of the process and other semi-random factors).

Given this and widespread reports of crashes in Explorer as well as other 3rd party apps, it seems likely these recent windows builds are simply duds. Even more the case when Opus itself did not change and remains stable on non-beta versions of Windows, but the beta Windows code changed and made things unstable (not just in Opus).

It doesn't make sense for us (GPSoftware) to spend more time on this as it's a Microsoft bug in a beta version of their OS, and is affecting more than just Opus. We could not fix their code without the source code, which we obviously do not have, and our time is best spend working on Opus rather than Windows.

You should report this to Microsoft, though, as they will want as much information as they can get from their beta testers (that's you, if you're in the Windows Insider program) so they can fix their code, which is why they are running a beta test. If you don't want to or don't know how to report bugs to Microsoft, it doesn't make sense to be beta testing an unstable pre-release versions of Windows. Wait for the stable version to come out instead.

Not to argue--but where are you seeing this reports? They are not on the official or un-official forums that I can find. And I've been running a multitude of programs over the last three day, even File Explorer with no problems. Totally agree with your point about the beta, but given how close the code is to the anniversary release I thought you might be interested. Is my post on page one accurate? I was going to submit the WindowsCodecsExt.dll as a potential problem to Microsoft.

I linked to one on the previous page, and there are some confirmations in the replies to that tweet, if I remember correctly. I didn't keep track of where I saw others similar reports/comments, but have seem people say Explorer was crashing all the time with 14376, and I think some mentioned other software as well (Edge and Firefox maybe? I forget to be honest), in addition to the linked tweet saying it's causing problems for all sorts of things.

Haven't seen much feedback either way with 14379 so far, but that's fairly normal. Feedback on Windows beta versions isn't something I seek out (as I'm not beta testing Windows). It was unusual to see the 14376 feedback that I did run into. Windows betas are presumably uneventful enough that people rarely talk about them, but 14376 seems broken enough that it has hit my radar more than once.

Yes, the post with the process explorer screenshot looks accurate, although WindowsCodecsExt.dll is probably an innocent bystander.

If you combine that with my stack dump screenshot above, it seems to confirm my theory that the bug is triggered by random memory being executed (probably because a table of callback functions that the Event Tracing Functions API, which I assume Windows itself is using for telemetry, has been corrupted). It's two completely different DLLs in each of our cases (in my case, one of our own DLLs, but a random place in memory that has no valid code in it; in your case, one of the Windows DLLs).

Thanks for the responses Leo! Fortunately the crashes are infrequent enough that I can still enjoy playing with the new features in 12.0.8.

Have posted a ink to Leo's reply with the call stack information in, to the Feedback Hub.

Since installing 12 b 8 2nd version to fix tag causing Opus to crash and close this morning I have not had any Program Errors Encountered messages.
Has anyone else noticed this.

Spoke to soon have just had a Program Error Encountered.

Funny. after a reboot of Win10 version 14379, I have not had an error yet today.

I too am experiencing intermittent failures in DOpus 11.x since updating to the W10 Pro Preview. At first I was running 11.18beta so I upgraded to final 11.19x64 hoping it would fix the crashes but it did not. I have not been on my computer for 5-hours and when I did use it about 15-minutes ago, the screen had the "Directory Opus has encountered....." window (4-crashes so far today) saying "The error (0xC0000005) occurred in thread 0xC64)..." but I can not find anything in the Windows Event Logs to get more details. Yes I have read this thread and mostly agree that since the big/major change was the OS, the problem is most likely caused by the OS. However, if MS does not fix/address the problem, lots of folks using W10 and DOpus will suddenly start having crashes when their W10 gets automagically updated to the "anniversary update/release".

That's why it's important that you report the issue to Microsoft.

I've spent most of this morning with an Insider build in a VM trying to work out what could be causing this problem. Could people who have this issue please try the following to see if it makes a difference for you:

  1. Press Windows+R (or Start -> Run) and enter services.msc to open the Services control panel.
  2. Locate the Connected User Experiences and Telemetry service, select it, and click the stop button at the top of the window to stop the service.
    (note that if Opus is running, it will probably crash immediately at this point)
  3. Right-click the same service entry, select Properties from the context menu, and change the Startup type to Disabled. Click OK.
  4. Restart your machine

After doing this, the service (which seems to be involved in tracking and telemetry) should no longer be running. See if this makes a difference to your Opus stability in the Insider build.

(note: because the crashes do seem to be random, you may have to try it for a day or two at least to see if it's made any difference.)

Jon
Have done what you suggested.
Opus did crash.
All I have to do is wait and see.

Jon. Your detective work appears to have done the trick. Well done.

Regards, AB

I have also disabled Connected User Experiences and Telemetry and it seems to be working for me too!

Glad it seems to have fixed it. But the advice from our end remains the same - report it to Microsoft! They're the only ones who can fix it.

Looks to help certainly (work PC) and I've reported to Microsoft. Will try the machine at home later.

I have also had no program errors since stopping the service.
I have put an entry in the Feedback Hub with the workaround that Jon suggested and asking Microsoft to fix.