Hallo hierbij wilde ik een crash rapporteren:

Toepassingsnaam met fout: WsMMPlay.exe, versie: 19.2.0.6, tijdstempel: 0x5c4e7164 Naam van foutmodule: msmpeg2ac3dec.dll, versie: 10.0.26100.9549, tijdstempel: 0xe4c86d1a Uitzonderingscode: 0xc0000602 Foutoffset: 0x00053ebc Foutproces-id: 0x2108 Begintijd van foutieve toepassing: 0x1DD4C2CFF449D0C Faulting-toepassingspad: C:\Program Files (x86)\Winstep\WsMMPlay.exe Faulting-modulepad: C:\WINDOWS\System32\msmpeg2ac3dec.dll Rapport-id: 5b9dbc1a-d67c-4b95-8330-e3e2b2e2f349 Faulting-pakket volledige naam: Faulting-pakket-relatieve toepassings-id:

Windows 11 Pro 26200.9550 sinds update v26.9, Winstep Extreme, Workshelf

Chatgpt zegt:

Ja, hiermee is de oorzaak een stuk duidelijker.

De crash zit niet primair in Winstep zelf, maar in de Windows-mediacodec:

WsMMPlay.exe → Winstep 19.2
Faulting module: C:\Windows\System32\msmpeg2ac3dec.dll
Dat is de Microsoft MPEG-2/AC-3 audio decoder
0xc0000602 wijst op een ernstige runtime-/compatibiliteitsfout in die module.

Opvallend is dat je een erg oude Winstep-versie (19.2.0.6) gebruikt. Die dateert uit 2019, terwijl de msmpeg2ac3dec.dll afkomstig is uit een veel nieuwere Windows 11-build. Dat maakt een compatibiliteitsprobleem tussen de oude WsMMPlay en de huidige Windows-mediacomponenten aannemelijk.

tijdelijke oplossing:

uitzetten voice weergave (audio weergave werkt wel goed)

Graag svp oplossen next time workshelf update!

First of all, this is an English-language forum. English is not my native language either, nor is it the native language of many of the people posting here, but everyone is expected to make the effort to use English so that everybody can understand and participate.

Since you are already using ChatGPT, there is really no excuse for posting an entire message in Dutch. You can simply ask ChatGPT to translate it into English before submitting it.

From now on, posts made by you entirely in languages other than English will be ignored.

Now:

The crash report actually shows that the failure is occurring inside a Microsoft Windows audio codec:

C:\Windows\System32\msmpeg2ac3dec.dll

and not inside WorkShelf itself.

WsMMPlay.exe is not an audio decoder. It is a very small helper process used by WorkShelf to pass playback commands to the Windows MCI multimedia subsystem. Windows itself then loads and uses the appropriate codecs to decode the audio.

In fact, WsMMPlay exists as a separate process for precisely this reason: multimedia codecs and filters have historically not always been reliable. If one of them crashes, WsMMPlay can terminate without bringing the whole Winstep application down with it.

The fact that WsMMPlay reports version 19.2.0.6 also does NOT mean you are running Winstep v19.2. WsMMPlay is a VERY SIMPLE separate helper executable whose code has simply not needed to change for many years. ChatGPT's conclusion that this is therefore an incompatibility between an old 2019 version of Winstep and modern Windows is totally incorrect.

Also, please do not assume that because you first noticed this "since the v26.9 update" the Winstep update must therefore be the cause. Windows itself has also been updated in the meantime. Microsoft's September Windows update included a very large number of fixes and changes, and it is already known to have introduced a number of issues of its own.

More importantly, WsMMPlay itself has not been updated in years. The Winstep component responsible for handing the sound over to Windows is therefore exactly the same code that was working before. What has changed is the environment around it - Windows itself, its multimedia components, codecs and filters.

So the fact that you first noticed the problem after installing v26.9 does not make v26.9 the cause.

What is unusual here is that the module actually crashing appears to be Microsoft's own msmpeg2ac3dec.dll. Problems of this type are more commonly caused by buggy third-party codec packs or filters such as K-Lite, although third-party filters can still participate in the Windows multimedia playback chain.

The exception code 0xC0000602 is also a native "fail fast" exception. In other words, the Windows multimedia component deliberately terminates the process immediately when the failure occurs.

Please let me know whether you have K-Lite or any other third-party codec pack installed, and, if possible, which exact voice/sound causes the crash. That will help determine whether the problem is specific to one audio file or to the Windows codec configuration on your system.

In other words, this is not a bug in the Winstep application, but in whatever external codec or filter Windows is invoking to decode the audio stream. WsMMPlay merely passes the playback request to the Windows multimedia subsystem - it performs no audio decoding itself - so the actual failure necessarily lies in one of those external multimedia components.

Also, is there an error dialog showing the exception? If so, could you post a screenshot of the dialog, please? Does it say "ActiveMovie Window" in the title?

Windows build 26200.9550 corresponds to KB5124010, Microsoft's optional October Preview cumulative update - released on September 22, 2026!!!!

This has NOTHING to do with the Winstep application itself. The date of the preview release simply happened to coincide almost exactly with the new Winstep update.

Nothing related to sound playback changed in v26.9. The Talking Clock is still using the same MP3 files, and WsMMPlay.exe itself has not been modified in years.

I've now had a couple of other reports, and they all seem to have one thing in common: the affected users appear to be either running Windows Insider builds or installing Microsoft's optional preview updates for the following month's Patch Tuesday release.

You like living life in the fast lane, you assume the risk that comes with it. Have you not learned your lesson yet?! Even OFFICIAL Windows releases and updates are riddled with bugs and regressions these days!!!!

Please notify Microsoft that there is an issue with multimedia playback in their preview builds/updates, and include the fact that in your case the crash occurs inside Microsoft's own msmpeg2ac3dec.dll.

Assuming they will even listen to you.

This is not isolated to Winstep anymore.

A fairly active Fallout: New Vegas thread reports that KB5124010 makes the game crash because of the same msmpeg2ac3dec.dll; users report that uninstalling KB5124010 restores the game, and some also report similar failures in Morrowind and WinTV. One commenter specifically notes that replacing the new decoder with the older 10.0.26100.8737 build restores operation.

WsMMPlay is collateral damage from KB5124010, not from Winstep v26.9.

Hello Winstep, thank you for your quick and exuberant clearification of this MS logging crashreport. It is clear now I have to wait for Microsoft to resolve this crash (or not) with a future update fix.

KB5124010 > Microsoft AC-3 decoder regression > Microsoft officially confirmed > no Microsoft fix yet.

The WsMMPlay.exe crash is a known Windows 11 KB5124010 issue acknowledged by Microsoft:
Microsoft's KB5124010 known-issues page

Look under "Applications which require AC-3 audio decoding might close unexpectedly"

There is also a useful clarification about which PCs are vulnerable: Microsoft documents that AC-3 was included before Windows 11 24H2 but removed from clean 24H2 installations; upgraded machines retain it. That explains why the bug can appear on upgraded 24H2/25H2 systems while an apparently identical clean installation doesn't reproduce it.

For those who want to know more:

The irony is that WsMMPlay.exe does not even use the AC-3 decoder to decode the MP3 voices/files (actually the player does no decoding at all, it simply issues a Multimedia "Play" Command with the actual MP3 sound file and lets Windows handle the rest).

Anyway, the crash happens before the actual decoding, while DirectShow is trying to build the playback graph.

DirectShow’s IGraphBuilder::RenderFile uses something called Intelligent Connect. Rather than the application explicitly saying "this is MP3, use decoder X," DirectShow looks at the source/filter outputs and tries candidate filters that might connect. That means it can instantiate filters that ultimately won’t be part of the final graph.

So, simplified, the sequence is roughly:

1. WsMMPlay.exe asks DirectShow to render an MP3 file.
2. DirectShow identifies the source stream and starts looking for filters that might accept it.
3. During that search, Windows considers the built-in Microsoft DSHOW AC-3 Decoder implemented in msmpeg2ac3dec.dll.
4. DirectShow instantiates that AC-3 decoder to ask, essentially, “can you connect to this stream?”
5. It eventually determines that it isn't the appropriate decoder for the MP3 and moves on.
6. The proper MPEG/MP3 decoder gets selected and actually performs playback.
Normally, step 4 is harmless. A filter being instantiated and rejected is routine DirectShow behaviour.

The September 22 optional preview update appears to have broken something inside the new msmpeg2ac3dec.dll, however. In the affected applications, creating/probing that decoder more than once in the process can trigger the fail-fast 0xC0000602 crash.

So the irony is:

The AC-3 decoder crashes the application even though it was never going to decode the MP3.

It is effectively dying during DirectShow's filter-discovery / graph-negotiation process, not during actual audio decoding.

###

This should give you a glimpse into why the Winstep application uses a separate applet to play MP3 audio instead of playing the audio itself.

This actually came about many years ago, after weeks - possibly even months, I don't remember now - of frustrating debugging finally led me to the conclusion that the reason the Winstep application was unstable on some systems but not others had, once again, absolutely nothing to do with Winstep itself.

The culprit was buggy third-party codec filters installed by codec packs such as K-Lite.

Worse, unlike what is happening now, the faulty codec did not crash the application immediately. Instead, it could corrupt the application's state in ways that later caused serious side effects seemingly completely unrelated to audio playback, making the actual cause extremely difficult to track down.

And, of course, as usual when a third-party DLL loaded inside the Winstep process craps out, it is the Winstep application itself that gets the blame.

The solution was to isolate audio playback in a separate process. If a buggy codec or Windows multimedia component crashes or corrupts that process, WsMMPlay.exe dies - not the main Winstep application. It can simply be restarted the next time audio needs to be played.