Skip to content

Instantly share code, notes, and snippets.

@basperheim

basperheim/fix-direct-draw-windows-issues.md

Last active June 29, 2026 00:17
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save basperheim/83650a26d26dc2325f5f12f0c3be191c to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save basperheim/83650a26d26dc2325f5f12f0c3be191c to your computer and use it in GitHub Desktop.
Download ZIP
Fix Windows 11 compatibility and Direct Draw issues with old GOG games
Raw
fix-direct-draw-windows-issues.md

Running Deadlock II: Shrine Wars on Windows 11 — DrawInit failed, DDrawCompat crashes, and rendering corruption

This documents the troubleshooting process used to get the GOG release of Deadlock II: Shrine Wars running on Windows 11.

The original problem was:

DrawInit failed

Several common legacy-game fixes did not solve it. Multiple versions of DDrawCompat also crashed inside their own ddraw.dll. The game eventually worked by removing the local DirectDraw wrapper, using Windows compatibility settings, forcing 640×480, and running the game fullscreen without the -w argument.

This is a troubleshooting report, not a universal guarantee. Old DirectDraw games can behave differently across GPUs, drivers, Windows builds, refresh rates, and laptop hybrid-graphics configurations.

System

Operating system: Windows 11, 64-bit
Processor:        Intel Core i5-13450HX
Memory:           32 GB
Graphics:
  - NVIDIA GeForce RTX 5050 Laptop GPU
  - Intel UHD Graphics
Display:          144 Hz
Game release:     GOG
Install path:     C:\GOG Games\Deadlock 2
Executable:       DEADLOCK.EXE

The game directory contained:

C:\GOG Games\Deadlock 2\DEADLOCK.EXE

Other executables included:

DLPARSE.EXE
dxcfg.exe
unins000.exe

DEADLOCK.EXE was the actual game executable.

Original symptoms

Launching the game normally produced:

DrawInit failed

This indicates that the game failed while initializing its old DirectDraw-based graphics path.

The following did not solve the problem:

  • Installing the legacy DirectX 9 redistributable
  • Enabling the Windows DirectPlay feature
  • Trying generic compatibility settings
  • Running the game as administrator
  • Trying several versions of DDrawCompat

The machine is vastly more powerful than the game requires. This was not a performance problem. It was a compatibility problem involving a late-1990s graphics API and a modern Windows display stack.

Attempt 1: DDrawCompat v0.7.1

DDrawCompat is installed by placing its compiled ddraw.dll beside the game executable.

The release archive was downloaded manually and extracted with PowerShell:

$zipPath = "$HOME\Downloads\DDrawCompat-v0.7.1.zip"
$extractPath = "$HOME\Downloads\DDrawCompat-v0.7.1"

Remove-Item $extractPath -Recurse -Force -ErrorAction SilentlyContinue

Expand-Archive `
    -Path $zipPath `
    -DestinationPath $extractPath

The extracted file was:

C:\Users\Benji\Downloads\DDrawCompat-v0.7.1\ddraw.dll

It was copied into the game directory:

Copy-Item `
    "$HOME\Downloads\DDrawCompat-v0.7.1\ddraw.dll" `
    "C:\GOG Games\Deadlock 2\ddraw.dll"

The game directory then contained:

DEADLOCK.EXE
ddraw.dll

This is how local DLL wrappers work on Windows. When the game requests ddraw.dll, the local DLL beside the executable may be loaded instead of the normal Windows DirectDraw implementation.

The wrapper did load successfully. Its log contained:

DDrawCompat loaded successfully

It also detected the Intel graphics adapter:

Adapter name: Intel(R) UHD Graphics 770

However, the game crashed shortly afterward.

The Windows Application event log showed:

Faulting application name: DEADLOCK.EXE
Faulting module name: DDRAW.dll
Exception code: 0xc0000005

The exception code:

0xc0000005

is an access violation.

The important result was that the crash occurred inside the local DDrawCompat DLL:

C:\GOG Games\Deadlock 2\DDRAW.dll

DDrawCompat v0.7.1 did not solve the problem on this system. It replaced the original DrawInit failed dialog with a silent crash.

Attempt 2: DDrawCompat v0.6.0

The v0.7.1 DLL was preserved by renaming it:

cd 'C:\GOG Games\Deadlock 2'

Rename-Item `
    '.\ddraw.dll' `
    'ddraw-v0.7.1.dll'

Rename-Item `
    '.\DDrawCompat-DEADLOCK.log' `
    'DDrawCompat-DEADLOCK-v0.7.1.log'

Only a file named exactly ddraw.dll is active as the local wrapper. A renamed file such as:

ddraw-v0.7.1.dll

is just an inactive backup.

Version 0.6.0 was extracted:

$zipPath = "$HOME\Downloads\DDrawCompat-v0.6.0.zip"
$extractPath = "$HOME\Downloads\DDrawCompat-v0.6.0"

Remove-Item $extractPath -Recurse -Force -ErrorAction SilentlyContinue

Expand-Archive `
    -Path $zipPath `
    -DestinationPath $extractPath

It was copied into the game directory:

Copy-Item `
    "$HOME\Downloads\DDrawCompat-v0.6.0\ddraw.dll" `
    "C:\GOG Games\Deadlock 2\ddraw.dll"

The installed version was verified with:

(Get-Item 'C:\GOG Games\Deadlock 2\ddraw.dll').VersionInfo |
    Select-Object FileVersion, ProductVersion

Output:

FileVersion ProductVersion
----------- --------------
v0.6.0      v0.6.0

The v0.6.0 log showed that it completed its hook installation:

DDrawCompat loaded successfully
Installing DirectDraw hooks
Installing Direct3D hooks
Installing GDI hooks
Finished installing hooks

Nevertheless, the game crashed again.

The Windows event log showed:

Faulting module name: DDRAW.dll
Exception code: 0xc0000005

Again, the faulting module was the local DDrawCompat DLL.

This ruled out the idea that the failure was unique to v0.7.1.

Attempt 3: DDrawCompat v0.4.0

Version 0.6.0 was archived:

cd 'C:\GOG Games\Deadlock 2'

Rename-Item `
    '.\ddraw.dll' `
    'ddraw-v0.6.0.dll'

Rename-Item `
    '.\DDrawCompat-DEADLOCK.log' `
    'DDrawCompat-DEADLOCK-v0.6.0.log'

Version 0.4.0 was extracted:

$zipPath = "$HOME\Downloads\DDrawCompat-v0.4.0.zip"
$extractPath = "$HOME\Downloads\DDrawCompat-v0.4.0"

Remove-Item $extractPath -Recurse -Force -ErrorAction SilentlyContinue

Expand-Archive `
    -Path $zipPath `
    -DestinationPath $extractPath

It was copied into the game folder:

Copy-Item `
    "$extractPath\ddraw.dll" `
    "C:\GOG Games\Deadlock 2\ddraw.dll"

The version was verified:

(Get-Item "C:\GOG Games\Deadlock 2\ddraw.dll").VersionInfo |
    Select-Object FileVersion, ProductVersion

Output:

FileVersion ProductVersion
----------- --------------
v0.4.0      v0.4.0

With v0.4.0, the game exited almost immediately.

DDrawCompat created zero-byte logs:

DDrawCompat-DEADLOCK.log
DDrawCompat-DEADLOCK[2].log

Their sizes were confirmed with:

Get-Item -LiteralPath '.\DDrawCompat-DEADLOCK[2].log' |
    Select-Object Name, Length, LastWriteTime

Output:

Name                        Length
----                        ------
DDrawCompat-DEADLOCK[2].log      0

Because the log was empty, there was nothing to read.

A literal path was required because square brackets have special wildcard meaning in PowerShell:

Get-Content `
    -LiteralPath '.\DDrawCompat-DEADLOCK[2].log' `
    -Tail 100

That command produced no output because the file contained zero bytes.

At this point, three DDrawCompat versions had failed:

v0.7.1: loaded, then crashed inside DDRAW.dll
v0.6.0: loaded, installed hooks, then crashed inside DDRAW.dll
v0.4.0: exited before writing a usable log

Continuing to test arbitrary wrapper versions was no longer productive.

The fix

The active wrapper was disabled by renaming the file named exactly ddraw.dll:

cd 'C:\GOG Games\Deadlock 2'

Rename-Item `
    '.\ddraw.dll' `
    'ddraw-v0.4.0.dll'

The absence of an active wrapper was verified:

Test-Path '.\ddraw.dll'

Expected output:

False

The renamed wrapper files remained in the directory as backups:

ddraw-v0.4.0.dll
ddraw-v0.6.0.dll
ddraw-v0.7.1.dll

These files are inactive because none is named exactly:

ddraw.dll

The game was then run using Windows compatibility settings.

The working configuration was:

Windows XP Service Pack 3 compatibility mode: enabled
Run in 640 × 480 screen resolution: enabled
Reduced color mode: disabled
Local ddraw.dll wrapper: absent
Windowed-mode -w argument: absent

The game then opened and ran fullscreen.

“Run this program as administrator” was enabled during some testing, but it was probably not relevant to the graphics fix. It can generally be disabled unless the game cannot save or modify its own files.

The effective fix was therefore:

Remove the crashing local DDrawCompat DLL
+ use Windows compatibility shims
+ force 640×480
+ run fullscreen

Why removing ddraw.dll helped

The file:

C:\GOG Games\Deadlock 2\ddraw.dll

was not an original game file. It was the DDrawCompat wrapper.

While that exact filename existed beside DEADLOCK.EXE, the game loaded the wrapper during DirectDraw initialization.

The evidence showed that:

  • DDrawCompat loaded successfully in v0.6.0 and v0.7.1
  • Windows reported DDRAW.dll as the faulting module
  • Both versions crashed with access violations
  • v0.4.0 failed even earlier

Renaming the DLL prevented Windows from treating it as the local DirectDraw implementation. The game then went back to using the Windows-provided DirectDraw path, together with Windows compatibility shims.

Removing ddraw.dll did not magically modernize the game. It removed a wrapper that was demonstrably crashing on this machine.

Why -w caused purple and black corruption

The game could also be launched with:

.\DEADLOCK.EXE -w

The -w argument enabled windowed mode.

In windowed mode, the game opened, but the interface showed large black and magenta rectangular artifacts. Some buttons, text, and screen regions appeared partially missing or overwritten.

This was not ordinary screen tearing.

Traditional screen tearing usually appears as horizontal discontinuities between different frames. The observed corruption looked more like:

  • stale surface contents
  • incomplete redraws
  • broken palette handling
  • mismatched GDI and DirectDraw surfaces
  • rectangles copied from the wrong buffer or not copied at all

Deadlock II is an old Windows game that appears to combine DirectDraw rendering with ordinary Windows GDI interface drawing.

That arrangement is particularly fragile in windowed mode because the game must cooperate with:

  • Windows repaint messages
  • clipping regions
  • the desktop compositor
  • GDI window contents
  • DirectDraw offscreen and primary surfaces

A modern Windows desktop does not behave exactly like the Windows 95/98-era environment for which the game was written.

Fullscreen mode avoids some of that complexity. The game can render against a display surface more similar to the environment it originally expected.

The practical result was:

With -w: game runs, but UI is badly corrupted
Without -w: game runs fullscreen and displays correctly

Therefore, -w was removed.

Final working launch method

From PowerShell:

cd 'C:\GOG Games\Deadlock 2'

.\DEADLOCK.EXE

Do not add:

-w

Do not place a third-party file named:

ddraw.dll

beside the executable unless intentionally testing another wrapper.

Recommended compatibility settings:

Compatibility mode:
  Windows XP (Service Pack 3)

Settings:
  Run in 640 × 480 screen resolution: enabled
  Reduced color mode: disabled
  Disable fullscreen optimizations: optional
  Run as administrator: normally disabled

Avoid changing several compatibility options at once after reaching a working state. Old games can be sensitive to combinations of shims, and uncontrolled changes make regressions difficult to diagnose.

Capturing future late-game crashes

Deadlock II may still occasionally crash during a long or late-game session.

Launching it from PowerShell does not automatically produce a detailed stack trace, but PowerShell can record the launch time, wait for the process to end, show its exit code, and query the Windows Application event log afterward.

Launch the game and record the session time

cd 'C:\GOG Games\Deadlock 2'

$startedAt = Get-Date

$process = Start-Process `
    '.\DEADLOCK.EXE' `
    -PassThru `
    -Wait

"Exit code: $($process.ExitCode)"
"Started:   $startedAt"
"Ended:     $(Get-Date)"

Notes:

  • -PassThru returns a process object.
  • -Wait keeps PowerShell waiting until the game exits.
  • $process.ExitCode records the process exit code.
  • $startedAt can be used to filter Windows events to the current session.

A nonzero exit code can indicate abnormal termination, but old programs are not always consistent about meaningful exit codes.

Read crash-related Windows events after the game exits

Run this after the game crashes or closes:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Application'
    StartTime = $startedAt
} |
Where-Object {
    $_.ProviderName -in @(
        'Application Error',
        'Windows Error Reporting',
        'Application Hang'
    )
} |
Sort-Object TimeCreated -Descending |
Select-Object `
    TimeCreated,
    ProviderName,
    Id,
    Message |
Format-List

Useful fields may include:

Faulting application name
Faulting module name
Exception code
Fault offset
Application path
Module path
Report ID

Interpretation examples:

Faulting module: DEADLOCK.EXE

This suggests that the fault occurred in the game executable itself.

Faulting module: some-driver.dll

This may implicate a graphics, audio, or system component.

Exception code: 0xc0000005

This is an access violation, meaning the process attempted to read, write, or execute invalid memory.

Provider: Application Hang

This indicates that Windows considered the application unresponsive rather than immediately crashed.

Save the Windows crash events to a text file

Get-WinEvent -FilterHashtable @{
    LogName   = 'Application'
    StartTime = $startedAt
} |
Where-Object {
    $_.ProviderName -in @(
        'Application Error',
        'Windows Error Reporting',
        'Application Hang'
    )
} |
Sort-Object TimeCreated -Descending |
Select-Object `
    TimeCreated,
    ProviderName,
    Id,
    Message |
Format-List |
Out-File `
    '.\deadlock-crash-log.txt' `
    -Encoding utf8

The output file will be:

C:\GOG Games\Deadlock 2\deadlock-crash-log.txt

Combined launch-and-log script

This combines launching the game, waiting for it to exit, recording its exit code, and exporting relevant Windows events.

Save the following as:

C:\GOG Games\Deadlock 2\Run-Deadlock-With-Logging.ps1

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'

$gameDirectory = 'C:\GOG Games\Deadlock 2'
$gameExecutable = Join-Path $gameDirectory 'DEADLOCK.EXE'
$logDirectory = Join-Path $gameDirectory 'SessionLogs'
$timestamp = Get-Date -Format 'yyyy-MM-dd_HH-mm-ss'
$logPath = Join-Path $logDirectory "deadlock-session-$timestamp.txt"

if (-not (Test-Path -LiteralPath $gameExecutable -PathType Leaf)) {
    throw "Game executable not found: $gameExecutable"
}

New-Item -ItemType Directory -Path $logDirectory -Force | Out-Null
Set-Location -LiteralPath $gameDirectory

$startedAt = Get-Date

@(
    'Deadlock II: Shrine Wars diagnostic session'
    "Started:    $startedAt"
    "Executable: $gameExecutable"
    ''
) | Out-File -LiteralPath $logPath -Encoding utf8

try {
    $process = Start-Process `
        -FilePath $gameExecutable `
        -WorkingDirectory $gameDirectory `
        -PassThru `
        -Wait

    $endedAt = Get-Date

    # Process.ExitCode is a signed Int32. Mask it to preserve the underlying
    # 32-bit Windows exception value without an invalid UInt32 cast.
    $exitCodeHex = '0x{0:X8}' -f (
        $process.ExitCode -band 0xFFFFFFFFL
    )

    @(
        "Ended:            $endedAt"
        "Exit code:        $($process.ExitCode)"
        "Exit code (hex):  $exitCodeHex"
        "Process ID:       $($process.Id)"
        ''
        'Relevant Windows Application events:'
        ''
    ) | Out-File -LiteralPath $logPath -Append -Encoding utf8
}
catch {
    @(
        ''
        'PowerShell encountered an error while launching or monitoring the game:'
        $_.Exception.ToString()
        ''
        'Relevant Windows Application events gathered despite the script error:'
        ''
    ) | Out-File -LiteralPath $logPath -Append -Encoding utf8
}
finally {
    $events = Get-WinEvent -FilterHashtable @{
        LogName   = 'Application'
        StartTime = $startedAt
    } -ErrorAction SilentlyContinue |
    Where-Object {
        $_.ProviderName -in @(
            'Application Error',
            'Windows Error Reporting',
            'Application Hang'
        )
    } |
    Sort-Object TimeCreated -Descending |
    Select-Object `
        TimeCreated,
        ProviderName,
        Id,
        Message

    if ($events) {
        $events |
            Format-List |
            Out-File `
                -LiteralPath $logPath `
                -Append `
                -Encoding utf8
    }
    else {
        'No matching Windows Application events were found.' |
            Out-File `
                -LiteralPath $logPath `
                -Append `
                -Encoding utf8
    }

    Write-Host ''
    Write-Host 'Session log written to:'
    Write-Host $logPath
}

Run it with:

cd 'C:\GOG Games\Deadlock 2'

powershell.exe `
    -ExecutionPolicy Bypass `
    -File '.\Run-Deadlock-With-Logging.ps1'

Each run creates a timestamped file such as:

deadlock-session-2026-06-11_14-32-08.txt

This is more useful than repeatedly overwriting one log.

Information to record when a late-game crash occurs

Windows crash data is useful, but game-state information matters too.

Record:

Turn number
Map or scenario
Number of players
Approximate game duration
Whether combat had just started or ended
Whether the AI was processing its turn
Whether the crash occurred during saving or loading
Whether the same save reproduces the crash
Whether loading an earlier save avoids it
Faulting module from Windows Event Viewer
Exception code
Process exit code

The distinction between reproducible and random crashes is important.

A crash that always occurs after loading the same save and performing the same action likely indicates:

  • a deterministic game bug
  • corrupt save data
  • an invalid late-game object or state
  • an AI-processing bug

A crash that occurs at inconsistent times may suggest:

  • memory corruption
  • timing sensitivity
  • audio or graphics driver interaction
  • an uninitialized variable
  • accumulated resource exhaustion

Save-management recommendation

Use rotating manual save slots instead of repeatedly overwriting one save.

For example:

campaign-01
campaign-02
campaign-03
campaign-04
campaign-05

Rotate through them in order.

Also keep occasional milestone saves:

campaign-turn-050
campaign-turn-100
campaign-turn-150

This protects against:

  • save corruption
  • deterministic late-game crashes
  • accidentally saving immediately before a broken game state
  • losing an entire campaign to one damaged file

Useful PowerShell commands from this investigation

Find game executables

Get-ChildItem `
    'C:\GOG Games\Deadlock 2' `
    -Filter '*.exe'

Find DDrawCompat-related files

Get-ChildItem `
    'C:\GOG Games\Deadlock 2' `
    -Filter '*ddraw*'

Verify an installed wrapper version

(Get-Item 'C:\GOG Games\Deadlock 2\ddraw.dll').VersionInfo |
    Select-Object FileVersion, ProductVersion

Verify that no active local wrapper exists

Test-Path 'C:\GOG Games\Deadlock 2\ddraw.dll'

Expected for the final working configuration:

False

Extract a ZIP archive

$zipPath = "$HOME\Downloads\DDrawCompat-v0.6.0.zip"
$extractPath = "$HOME\Downloads\DDrawCompat-v0.6.0"

Remove-Item $extractPath -Recurse -Force -ErrorAction SilentlyContinue

Expand-Archive `
    -Path $zipPath `
    -DestinationPath $extractPath

Read the last 100 lines of the newest matching log

$latestLog = Get-ChildItem `
    -Path 'C:\GOG Games\Deadlock 2' `
    -Filter 'DDrawCompat*.log' |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 1

if ($null -ne $latestLog) {
    Get-Content `
        -LiteralPath $latestLog.FullName `
        -Tail 100
}

Using -LiteralPath prevents filenames containing square brackets from being interpreted as wildcard expressions.

Read a filename containing literal square brackets

Get-Content `
    -LiteralPath '.\DDrawCompat-DEADLOCK[2].log' `
    -Tail 100

Find recent Application Error events

Get-WinEvent -FilterHashtable @{
    LogName   = 'Application'
    StartTime = (Get-Date).AddMinutes(-5)
} |
Where-Object {
    $_.ProviderName -eq 'Application Error'
} |
Sort-Object TimeCreated -Descending |
Select-Object `
    TimeCreated,
    ProviderName,
    Id,
    Message |
Format-List

Final result

The stable configuration found during this investigation was:

GOG release installed in:
C:\GOG Games\Deadlock 2

Active local ddraw.dll:
None

Compatibility mode:
Windows XP Service Pack 3

Forced resolution:
640 × 480

Launch argument:
No -w

Display mode:
Fullscreen

The game launched and rendered correctly under that configuration.

It may still crash occasionally in late-game sessions. Those crashes appear to be a separate problem from the original DrawInit failed issue and should be investigated using Windows Application events, process exit codes, reproducible save files, and timestamped session logs.

Condensed post-mortem

Initial failure

DrawInit failed

Failed approaches

Legacy DirectX runtime
DirectPlay
Generic compatibility changes
DDrawCompat v0.7.1
DDrawCompat v0.6.0
DDrawCompat v0.4.0

DDrawCompat evidence

Faulting module: DDRAW.dll
Exception code: 0xc0000005

Fix

Remove or rename local ddraw.dll
Enable Windows XP SP3 compatibility mode
Enable 640×480 compatibility resolution
Run fullscreen
Do not use -w

Windowed-mode symptom

Black and magenta rectangular corruption

Likely explanation

Broken synchronization between legacy DirectDraw surfaces,
GDI-based interface drawing, and the modern Windows compositor.

Current status

Game launches and renders correctly in fullscreen.
Occasional late-game crashes remain possible.

PowerShell Permission Issues Copying Logs

You hit a normal Windows permissions boundary. The rough PowerShell equivalent of sudo is not a command prefix; you launch an elevated PowerShell process.

From a normal PowerShell window:

Start-Process powershell.exe -Verb RunAs

That opens a new Administrator PowerShell window after a UAC prompt. Then run:

Get-ChildItem -LiteralPath `
  'C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_DEADLOCK.EXE_b8214626899817fa2d779ff6e56c2cdc662fbb96_95072099_860e708e-db68-4a99-bfff-1887984b91dc'

Or open Windows Terminal/PowerShell by right-clicking it and choosing Run as administrator.

Do not run the game itself as administrator just because the WER folder requires elevation. Those are separate concerns.

Do you need to keep using Start-Process -PassThru -Wait?

Only when you want to collect process information.

This:

$process = Start-Process `
    '.\DEADLOCK.EXE' `
    -PassThru `
    -Wait

does three useful things:

  • launches the game
  • waits until it exits
  • saves the process object into $process

That lets you read:

$process.ExitCode
$process.StartTime
$process.ExitTime
$process.Id

For ordinary play, you can just launch it normally:

.\DEADLOCK.EXE

or use the desktop shortcut.

PowerShell Script Shortcut

For diagnostic sessions, use a script. Re-entering five commands manually every time is pointless friction.

Save this as:

C:\GOG Games\Deadlock 2\Run-Deadlock-With-Logging.ps1

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'

$gameDirectory = 'C:\GOG Games\Deadlock 2'
$gameExecutable = Join-Path $gameDirectory 'DEADLOCK.EXE'
$logDirectory = Join-Path $gameDirectory 'SessionLogs'
$timestamp = Get-Date -Format 'yyyy-MM-dd_HH-mm-ss'
$logPath = Join-Path $logDirectory "deadlock-session-$timestamp.txt"

if (-not (Test-Path -LiteralPath $gameExecutable -PathType Leaf)) {
    throw "Game executable not found: $gameExecutable"
}

New-Item -ItemType Directory -Path $logDirectory -Force | Out-Null
Set-Location -LiteralPath $gameDirectory

$startedAt = Get-Date

@(
    'Deadlock II: Shrine Wars diagnostic session'
    "Started:    $startedAt"
    "Executable: $gameExecutable"
    ''
) | Out-File -LiteralPath $logPath -Encoding utf8

try {
    $process = Start-Process `
        -FilePath $gameExecutable `
        -WorkingDirectory $gameDirectory `
        -PassThru `
        -Wait

    $endedAt = Get-Date
    $exitCodeHex = '0x{0:X8}' -f ([uint32]$process.ExitCode)

    @(
        "Ended:            $endedAt"
        "Exit code:        $($process.ExitCode)"
        "Exit code (hex):  $exitCodeHex"
        "Process ID:       $($process.Id)"
        ''
        'Relevant Windows Application events:'
        ''
    ) | Out-File -LiteralPath $logPath -Append -Encoding utf8

    $events = Get-WinEvent -FilterHashtable @{
        LogName   = 'Application'
        StartTime = $startedAt
    } -ErrorAction SilentlyContinue |
    Where-Object {
        $_.ProviderName -in @(
            'Application Error',
            'Windows Error Reporting',
            'Application Hang'
        )
    } |
    Sort-Object TimeCreated -Descending |
    Select-Object TimeCreated, ProviderName, Id, Message

    if ($events) {
        $events |
            Format-List |
            Out-File -LiteralPath $logPath -Append -Encoding utf8
    }
    else {
        'No matching Windows Application events were found.' |
            Out-File -LiteralPath $logPath -Append -Encoding utf8
    }
}
catch {
    @(
        ''
        'PowerShell monitoring error:'
        $_.Exception.ToString()
    ) | Out-File -LiteralPath $logPath -Append -Encoding utf8

    throw
}
finally {
    Write-Host ''
    Write-Host 'Session log written to:'
    Write-Host $logPath
}

Run it with:

cd 'C:\GOG Games\Deadlock 2'

powershell.exe `
    -ExecutionPolicy Bypass `
    -File '.\Run-Deadlock-With-Logging.ps1'

That is the better approach: use the desktop shortcut normally, and use this script when you want evidence.

Copying the protected WER report

From an elevated PowerShell window:

$source = 'C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_DEADLOCK.EXE_b8214626899817fa2d779ff6e56c2cdc662fbb96_95072099_860e708e-db68-4a99-bfff-1887984b91dc'

$destination = 'C:\GOG Games\Deadlock 2\CrashReports\2026-06-11-1132'

New-Item `
    -ItemType Directory `
    -Path $destination `
    -Force |
    Out-Null

Copy-Item `
    -LiteralPath $source `
    -Destination $destination `
    -Recurse `
    -Force

One subtlety: that command may create a nested folder inside the destination. Check with:

Get-ChildItem `
    -LiteralPath $destination `
    -Recurse

Late-game crash traced to the Intel graphics driver

After the original launch issue was fixed, the game still occasionally crashed during longer sessions.

A diagnostic session was launched from PowerShell:

cd 'C:\GOG Games\Deadlock 2'

$startedAt = Get-Date

$process = Start-Process `
    '.\DEADLOCK.EXE' `
    -PassThru `
    -Wait

After the game exited, the process exit code was printed:

"Exit code: $($process.ExitCode)"
"Started:   $startedAt"
"Ended:     $(Get-Date)"

The result was:

Exit code: -1073741819

That signed decimal value corresponds to:

0xC0000005

0xC0000005 is a Windows access-violation exception.

The relevant Windows Application events were retrieved with:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Application'
    StartTime = $startedAt
} |
Where-Object {
    $_.ProviderName -in @(
        'Application Error',
        'Windows Error Reporting',
        'Application Hang'
    )
} |
Sort-Object TimeCreated -Descending |
Select-Object `
    TimeCreated,
    ProviderName,
    Id,
    Message |
Format-List

The important event contained:

Faulting application name: DEADLOCK.EXE
Faulting module name: igd9trinity32.dll
Exception code: 0xc0000005
Fault offset: 0x00d8ccbe

The faulting module path was:

C:\Windows\System32\DriverStore\FileRepository\
iigd_dch.inf_amd64_2c091df994bfd0bb\
igd9trinity32.dll

This DLL is part of Intel's 32-bit legacy graphics-driver path.

The observed call path was approximately:

Deadlock II
→ old DirectDraw or legacy graphics calls
→ Windows graphics compatibility path
→ Intel graphics driver
→ access violation

This does not necessarily prove that the Intel driver was solely responsible. A 1990s game can make unexpected or invalid graphics calls that expose a driver bug. However, it did prove that the actual fault occurred inside the Intel driver rather than inside DEADLOCK.EXE or a local DDrawCompat DLL.

Force Deadlock II to use the dedicated NVIDIA GPU

The next controlled test was to force the game to use the NVIDIA GPU instead of Intel integrated graphics.

On Windows 11:

  1. Open Settings.
  2. Open System.
  3. Open Display.
  4. Open Graphics.
  5. Click Add desktop app or Browse.
  6. Select:
C:\GOG Games\Deadlock 2\DEADLOCK.EXE
  1. Click the newly added application.
  2. Click Options.
  3. Select:
High performance
NVIDIA GeForce RTX 5050 Laptop GPU
  1. Click Save.

The game should still be launched fullscreen and without the -w argument:

cd 'C:\GOG Games\Deadlock 2'
.\DEADLOCK.EXE

This setting is stored by Windows, so the game does not need to be launched through a special PowerShell command every time.

To confirm which GPU the process is using:

  1. Open Task Manager.
  2. Open the Details tab.
  3. Right-click a column header.
  4. Choose Select columns.
  5. Enable GPU engine.
  6. Find DEADLOCK.EXE.

The GPU number can be mapped to the adapters shown on Task Manager's Performance tab.

PowerShell equivalent of sudo

PowerShell does not normally use a per-command sudo prefix.

To open an elevated PowerShell process:

Start-Process powershell.exe -Verb RunAs

Windows will display a User Account Control prompt.

Another option is to right-click PowerShell or Windows Terminal and choose:

Run as administrator

The elevated shell is only needed for protected locations such as:

C:\ProgramData\Microsoft\Windows\WER

The game itself should not normally be run as administrator merely because crash reports require elevated access.

Reading an archived Windows Error Reporting report

Windows Error Reporting may store reports under:

C:\ProgramData\Microsoft\Windows\WER\ReportArchive

These directories may reject access from a normal PowerShell session.

From an elevated PowerShell window:

$reportPath = 'C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_DEADLOCK.EXE_b8214626899817fa2d779ff6e56c2cdc662fbb96_95072099_860e708e-db68-4a99-bfff-1887984b91dc'

Get-ChildItem `
    -LiteralPath $reportPath `
    -Recurse

-LiteralPath is used so PowerShell does not interpret characters in the path as wildcards.

Copying a protected crash report

From an elevated PowerShell window:

$source = 'C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_DEADLOCK.EXE_b8214626899817fa2d779ff6e56c2cdc662fbb96_95072099_860e708e-db68-4a99-bfff-1887984b91dc'

$destination = 'C:\GOG Games\Deadlock 2\CrashReports\2026-06-11-1132'

New-Item `
    -ItemType Directory `
    -Path $destination `
    -Force |
    Out-Null

Copy-Item `
    -LiteralPath $source `
    -Destination $destination `
    -Recurse `
    -Force

Verify the copied contents:

Get-ChildItem `
    -LiteralPath $destination `
    -Recurse

Windows may eventually delete temporary WER files, so reports worth preserving should be copied promptly.

Normal launches versus diagnostic launches

For ordinary play, launch the game normally:

cd 'C:\GOG Games\Deadlock 2'
.\DEADLOCK.EXE

A desktop shortcut is also fine.

This command is only needed when collecting process information:

$process = Start-Process `
    '.\DEADLOCK.EXE' `
    -PassThru `
    -Wait

The options mean:

-PassThru
    Return a process object.

-Wait
    Keep PowerShell waiting until the process exits.

The resulting process object can expose:

$process.Id
$process.ExitCode
$process.StartTime
$process.ExitTime

For repeated diagnostics, use a reusable script rather than entering the commands manually.

Reusable launch-and-log script

Save this file as:

C:\GOG Games\Deadlock 2\Run-Deadlock-With-Logging.ps1

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'

$gameDirectory = 'C:\GOG Games\Deadlock 2'
$gameExecutable = Join-Path $gameDirectory 'DEADLOCK.EXE'
$logDirectory = Join-Path $gameDirectory 'SessionLogs'
$timestamp = Get-Date -Format 'yyyy-MM-dd_HH-mm-ss'
$logPath = Join-Path $logDirectory "deadlock-session-$timestamp.txt"

if (-not (Test-Path -LiteralPath $gameExecutable -PathType Leaf)) {
    throw "Game executable not found: $gameExecutable"
}

New-Item -ItemType Directory -Path $logDirectory -Force | Out-Null
Set-Location -LiteralPath $gameDirectory

$startedAt = Get-Date

@(
    'Deadlock II: Shrine Wars diagnostic session'
    "Started:    $startedAt"
    "Executable: $gameExecutable"
    ''
) | Out-File -LiteralPath $logPath -Encoding utf8

try {
    $process = Start-Process `
        -FilePath $gameExecutable `
        -WorkingDirectory $gameDirectory `
        -PassThru `
        -Wait

    $endedAt = Get-Date
    $exitCodeHex = '0x{0:X8}' -f ([uint32]$process.ExitCode)

    @(
        "Ended:            $endedAt"
        "Exit code:        $($process.ExitCode)"
        "Exit code (hex):  $exitCodeHex"
        "Process ID:       $($process.Id)"
        ''
        'Relevant Windows Application events:'
        ''
    ) | Out-File -LiteralPath $logPath -Append -Encoding utf8

    $events = Get-WinEvent -FilterHashtable @{
        LogName   = 'Application'
        StartTime = $startedAt
    } -ErrorAction SilentlyContinue |
    Where-Object {
        $_.ProviderName -in @(
            'Application Error',
            'Windows Error Reporting',
            'Application Hang'
        )
    } |
    Sort-Object TimeCreated -Descending |
    Select-Object `
        TimeCreated,
        ProviderName,
        Id,
        Message

    if ($events) {
        $events |
            Format-List |
            Out-File `
                -LiteralPath $logPath `
                -Append `
                -Encoding utf8
    }
    else {
        'No matching Windows Application events were found.' |
            Out-File `
                -LiteralPath $logPath `
                -Append `
                -Encoding utf8
    }
}
catch {
    @(
        ''
        'PowerShell monitoring error:'
        $_.Exception.ToString()
    ) | Out-File -LiteralPath $logPath -Append -Encoding utf8

    throw
}
finally {
    Write-Host ''
    Write-Host 'Session log written to:'
    Write-Host $logPath
}

Run it with:

cd 'C:\GOG Games\Deadlock 2'

powershell.exe `
    -ExecutionPolicy Bypass `
    -File '.\Run-Deadlock-With-Logging.ps1'

The script creates timestamped logs under:

C:\GOG Games\Deadlock 2\SessionLogs

Example:

deadlock-session-2026-06-11_15-42-19.txt

The script records:

Session start time
Session end time
Decimal exit code
Hexadecimal exit code
Process ID
Application Error events
Windows Error Reporting events
Application Hang events

The dedicated-GPU preference is managed by Windows and applies regardless of whether the game is launched from Explorer, a desktop shortcut, PowerShell, or the diagnostic script, and this GPU setting will persist. You do not need PowerShell to make Windows choose the NVIDIA GPU; the diagnostic wrapper is only for collecting crash evidence.

DosBox Config

Open Steam, go to the game page, and click the gear icon -> Manage -> Browse local files, and edit the dosbox.conf file like so:

[sdl]
fullscreen=false
fulldouble=false
fullresolution=original
#windowresolution=1280x960
#windowresolution=1360x1020
windowresolution=1300x975
output=opengl
autolock=true
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper.txt
usescancodes=true

[dosbox]
language=
machine=vga
captures=capture
memsize=32

[render]
frameskip=0
aspect=true
scaler=normal3x

[cpu]
core=auto
cycles=18000
cycleup=1200
cycledown=700

[mixer]
nosound=false
rate=22050
blocksize=4096
prebuffer=14

[midi]
mpu401=intelligent
device=default
config=

[sblaster]
sbtype=sb16
sbbase=220
irq=7
dma=1
hdma=5
mixer=true
oplmode=auto
oplrate=22050

[gus]
gus=false
gusrate=22050
gusbase=240
irq1=5
irq2=5
dma1=3
dma2=3
ultradir=C:\ULTRASND

[speaker]
pcspeaker=false
pcrate=22050
tandy=off
tandyrate=22050
disney=false

[joystick]
joysticktype=none
timed=true
autofire=false
swap34=false
buttonwrap=true

[serial]
serial1=disabled
serial2=disabled
serial3=disabled
serial4=disabled

[dos]
xms=true
ems=true
umb=true
keyboardlayout=none

[ipx]
ipx=false

[autoexec]
@echo off
mount c XCOM -freesize 1024
c:
cd XCOM
call ufocd.bat
exit
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment