Legacy LOB/Vertical Software Incompatibility — 32-bit or Outdated Applications Failing on Modern 64-bit Windows

Indicators

• Application fails to launch after OS upgrade with no meaningful error message
• Installer reports 'This application cannot run on this version of Windows' or similar incompatibility dialog
• 16-bit application error: 'This app can't run on your PC' — indicates 16-bit executable on 64-bit OS
• Missing DLL errors at launch (e.g., MSVBVM60.DLL not found, MSVCRT.DLL version mismatch)
• Application crashes immediately on start with Windows Error Reporting dialog (Event ID 1000)
• Application runs but produces incorrect output, garbled UI, or silent data corruption
• Installer fails partway through, leaving application partially installed

Likely causes

• 16-bit executables cannot run — 64-bit Windows lacks NTVDM (NT Virtual DOS Machine) subsystem
• 32-bit application accessing 64-bit registry hives or system paths without WOW64 redirection awareness
• Hard-coded paths to C:\Windows\System32 behaving differently under WOW64 redirection for 32-bit processes
• Dependency on deprecated or removed Windows APIs (older PSAPI, obsolete COM interfaces, legacy cryptographic providers)
• Missing Visual Basic 6, VC++ redistributable, or other legacy runtime libraries not present by default
• Application uses 32-bit kernel-mode drivers that cannot load on 64-bit kernel
• Installer relies on removed setup APIs or incompatible MSI schema versions
• Application relies on Internet Explorer ActiveX controls or MSHTML rendering engine behaviours removed in modern Windows

Diagnostic steps

1. Determine application bitness using PE headers. Run from Visual Studio Developer Command Prompt: dumpbin /headers application.exe | findstr /i "machine type subsystem" — look for 'machine (x86)' for 32-bit, 'machine (x64)' for 64-bit, or 'MS-DOS' / '16-bit' indicators. Alternative: use Dependency Walker or lucasg/Dependencies.
   Confirms whether application is 16-bit (cannot run on 64-bit Windows), 32-bit (runs under WOW64), or 64-bit.
2. Check Event Viewer Application log for crash entries. Navigate to Event Viewer > Windows Logs > Application, filter for Event ID 1000 (Application Error) and Event ID 1001 (Windows Error Reporting). Record faulting module name, version, and exception code.
   Identifies specific DLL or component causing the crash and exception type to narrow down missing dependency, access violation, or API incompatibility.
3. Run application under Process Monitor (Sysinternals) with filter set to application process name. Filter for 'NAME NOT FOUND' and 'ACCESS DENIED' results on file system and registry operations during startup.
   Reveals missing files, DLLs, or registry keys the application expects, and permission failures — the most common causes of silent startup failures.
4. Test built-in compatibility modes. Right-click executable > Properties > Compatibility tab. Try 'Windows XP (Service Pack 3)', 'Windows Vista', 'Run this program as an administrator', and 'Disable display scaling on high DPI settings'. Test each combination.
   Determines whether a built-in Windows compatibility shim resolves the failure without custom tooling.
5. Scan for missing DLL dependencies using Dependency Walker (depends.exe) or lucasg/Dependencies. Load the main executable and scan for DLLs marked with error icons or those it cannot locate.
   Produces definitive list of missing runtime libraries and incompatible DLL versions for targeted redistributable installation.
6. If application involves kernel-mode driver or service, check driver signing and bitness. Run: sc query <servicename> to confirm service state, check Device Manager > View > Show Hidden Devices for devices with error codes, and run: driverquery /v /fo list | findstr /i "<drivername>" to confirm driver load status.
   Identifies 32-bit kernel drivers that cannot load on 64-bit kernel — a hard blocker requiring vendor-supplied 64-bit driver or replacement.

Resolution path

• Step 1 — Install missing legacy runtimes: For VB6 applications, install Visual Basic 6.0 runtime (vbrun60sp6.exe). For VC++ applications, install the Visual C++ Redistributable package matching the application's build year (2005, 2008, 2010, 2013, 2015-2022). For .NET Framework dependencies, enable .NET 3.5: dism /online /enable-feature /featurename:NetFx3 /All
• Step 2 — Apply Windows compatibility shims via Compatibility Administrator: Install Windows ADK, open Compatibility Administrator, create a new application fix, apply relevant shims (VirtualRegistry, CorrectFilePaths, ForceAdminAccess, WinXPSP2VersionLie, SingleProcAffinity). Save as .sdb file and install: sdbinst.exe <fixname>.sdb
• Step 3 — Redirect hard-coded 32-bit path issues: If Process Monitor shows application looking in System32 when it should use SysWOW64, apply 'CorrectFilePaths' shim or create symbolic link: mklink /d C:\Windows\System32\<legacypath> C:\Windows\SysWOW64\<legacypath> — only where safe and non-destructive
• Step 4 — Isolate in compatibility environment if shims insufficient: Deploy application in Windows XP Mode VM (Hyper-V or VMware), Windows Sandbox with mapped network share access, or application virtualization solution (Microsoft App-V, Cameyo, Turbo.net)
• Step 5 — For 16-bit applications with no alternative: Evaluate DOSBox for DOS-era applications, or deploy dedicated Windows XP/32-bit VM with network isolation accessed via RDP or RemoteApp
• Step 6 — Engage vendor for upgrade path: Open support case referencing specific OS version, request 64-bit compatible build, migration tool, or official end-of-life statement to justify replacement procurement

Prevention

• Establish application inventory and compatibility assessment before OS upgrades: use Microsoft Upgrade Readiness / Endpoint Analytics or ACT to scan installed applications against target OS and flag 16-bit, unsigned, or known-incompatible applications before migration
• Define application lifecycle policy prohibiting procurement of software without vendor-confirmed support statement for current and next planned OS version
• Maintain standardised approved runtime library baseline (VC++ redistributables, .NET Framework versions, Java runtimes) deployed via SCCM/Intune to all endpoints
• For applications that cannot be modernised, document as technical debt with target replacement date and isolate in managed VM or RemoteApp environment rather than general-purpose endpoints
• Require vendors to provide 64-bit native build or written roadmap to 64-bit support as contractual condition of software procurement renewals

Tools

• Dependency Walker / lucasg/Dependencies — enumerate missing or mismatched DLL dependencies
• Process Monitor (Sysinternals) — trace file system and registry access failures in real time
• dumpbin (Visual Studio) — inspect PE headers for application bitness and subsystem
• Compatibility Administrator (Windows ADK) — create and deploy custom application compatibility shims (.sdb files)
• sdbinst.exe — install or uninstall custom shim database (.sdb) files
• DISM — enable optional Windows features such as .NET Framework 3.5
• Event Viewer — review Application log for crash event IDs 1000 and 1001
• driverquery — enumerate loaded drivers and confirm driver bitness and status
• sc.exe — query and manage Windows services
• DOSBox — emulate DOS environment for 16-bit DOS-era applications
• Microsoft App-V / Cameyo / Turbo.net — application virtualization to isolate legacy runtimes

References

• Windows Application Compatibility — Microsoft Docs
• Application Compatibility Toolkit (ACT) Documentation
• WOW64 Implementation Details — Microsoft Docs
• Visual Basic 6.0 Runtime Extended Support
• Microsoft App-V Documentation