Compatibility Report

• Name of the game with compatibility issues: Surviving Deponia Playtest
• Steam AppID: 4498200

Workaround TL;DR

With Proton 10.0-4, the game launches and the main menu renders correctly.

System Information

• CPU: Intel Core Ultra 7 265KF
• RAM: 32 GB
• GPU: NVIDIA GeForce RTX 5060 Ti
• Video driver version: NVIDIA 610.43.3
• Kernel: Linux 7.1.3-2-cachyos-deckify-lto x86_64
• Working Proton version: Proton 10.0-4
• Affected Proton version: Proton 11.0-1
• Game engine: AtomicTorch Engine (RENKEI Engine (c) by AtomicTorch Studio Pte. Ltd.)
• Relevant runtime: bundled .NET / CoreCLR; image loading uses SharpDX/WIC

I confirm:

• [X] that I haven't found an existing compatibility report for this game.
  "haven't found" - Tbf, yes but I currently didn't searched for, so thats why I could'nt find one - sorry, if a dupe exists
• [X] that I have checked whether there are updates for my system available.

PROTON_LOG=1

WINEDEBUG=+wincodecs,+seh PROTON_LOG=1 %command%

diff-steam-4498200.log
p11-steam-4498200.log
p10-steam-4498200.log

Symptoms

With Proton 10.0-4, the game launches and the main menu renders correctly.

With Proton 11.0-1, the game itself launches, but parts of the main menu fail to render correctly. The game log reports an exception while decoding an image through SharpDX/WIC:

System.NullReferenceException: Object reference not set to an instance of an object.

at ComStreamBaseVtbl.ReadImpl(thisPtr, buffer, sizeOfBytes, bytesRead)
at BitmapDecoder.GetFrame(index)
...

Using PROTON_USE_WINED3D=1 %command% same issue as well, so the issue does not appear to be DXVK-specific.

Switching back to Proton 10.0-4 immediately resolves the issue.

Reproduction

1. Install Surviving Deponia Playtest (AppID 4498200).
2. Force Proton 11
3. Launch the game and reach the main menu.
4. Observe incorrectly/missing rendered menu assets. (Main Menu is black; blackscreen)
5. The game log contains a System.NullReferenceException in:
   ComStreamBaseVtbl.ReadImpl -> BitmapDecoder.GetFrame.
6. Switch to Proton 10
7. Launch the same installation again.
8. The menu renders correctly.

Technical analysis

I compared WIC traces from Proton 10.0-4 and Proton 11.0-1.

The failing object in Proton 11 is created as:

CommonDecoder_CreateInstance
({9456a480-e88b-43ea-9e73-0b2d9b71b1ca}, ...)

9456a480-e88b-43ea-9e73-0b2d9b71b1ca is CLSID_WICJpegDecoder.

Proton 10.0-4

When the relevant JPEG reaches GetFrame(), the trace shows:

trace:wincodecs:CommonDecoder_GetFrame (...)
fixme:wincodecs:jpeg_decoder_get_metadata_blocks stub
trace:wincodecs:CommonDecoder_GetFrame -> 3840x2160, 24-bit ...

The frame is then processed normally and the game renders correctly.

Proton 11.0-1

For the corresponding JPEG decoder, GetFrame() enters a different code path:

trace:wincodecs:CommonDecoder_GetFrame (0000000013782D00,0,...)
trace:wincodecs:IWICStreamImpl_Seek (0000000013719BE0, 2, 0,...)
trace:wincodecs:IWICStreamImpl_Read
    (0000000013719BE0, 000000000783EDAC, 4, 0000000000000000)

warn:seh:dispatch_exception backtrace: --- Exception 0xc0000005.
trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION)
trace:seh:dispatch_exception info[0]=0000000000000001
trace:seh:dispatch_exception info[1]=0000000000000000

So immediately before the access violation, Wine calls the underlying stream as effectively:

IStream::Read(buffer, 4, NULL);

The access violation is a write to address 0.

The managed application stack identifies the callback receiving this call as:

SharpDX ... ComStreamBaseVtbl.ReadImpl(..., bytesRead)

and this becomes a managed:

System.NullReferenceException

The Proton trace subsequently also shows a CLR exception with:

info[0]=FFFFFFFF80004003

which is consistent with the NullReferenceException observed by the game.

Likely regression trigger

This appears closely related to the Wine change:

windowscodecs/jpeg: Add support for App1 metadata blocks in the decoder
Wine MR !7653

The new jpeg_decoder_get_metadata_blocks() implementation replaced the previous stub and contains calls equivalent to:

stream_seek(This->stream, 2, STREAM_SEEK_SET, NULL);

//...

if (stream_read(This->stream, header, 4, NULL) != S_OK)
    break;

as well as further stream_read(..., NULL) calls while parsing APP1/Exif metadata.

This matches the Proton 11 trace very closely:

Seek(..., 2, ...)
Read(..., 4, NULL)
ACCESS_VIOLATION

whereas Proton 10.0-4 still shows:

jpeg_decoder_get_metadata_blocks stub

and works.

API compatibility detail

According to the COM ISequentialStream::Read contract, pcbRead may be NULL if the caller is not interested in the number of bytes actually read.

Therefore Wine's call is apparently valid COM usage.

This suggests that the application/SharpDX stream implementation has a latent compatibility issue and assumes that pcbRead is always non-NULL. However, the application works with Proton 10 and fails with Proton 11 because the newer Wine WindowsCodecs JPEG metadata path exposes this behavior.

For that reason I am reporting this as a Proton regression / application compatibility regression, even though the underlying SharpDX behavior may technically be non-compliant or insufficiently defensive.

Possible Wine compatibility workaround

If avoiding NULL for pcbRead is acceptable for application compatibility, the JPEG metadata parser could use a local variable, for example:

ULONG bytes_read;

if (stream_read(This->stream, header, sizeof(header), &bytes_read) != S_OK ||
    bytes_read != sizeof(header))
    break;

instead of:

stream_read(This->stream, header, 4, NULL)

This is not necessary according to the COM API contract, but should avoid triggering the SharpDX stream implementation used by this game.

Test matrix

Proton 5.13 was just a tip from ChatGPT

Summary

The regression appears to be:

Proton 10:
WIC JPEG GetFrame
 -> jpeg_decoder_get_metadata_blocks() is a stub
 -> frame decode succeeds

Proton 11:
WIC JPEG GetFrame
 -> implemented JPEG APP1 metadata parser
 -> IStream::Read(..., pcbRead=NULL)
 -> SharpDX ComStreamBaseVtbl.ReadImpl
 -> write to NULL / 0xc0000005
 -> System.NullReferenceException
 -> menu image fails to render

The strongest suspect is therefore the interaction between the newer Wine windowscodecs JPEG APP1 metadata implementation and SharpDX's managed COM stream wrapper.