A Visual Basic 6 program is rarely just an EXE. Its real operating environment may include OCX controls, COM servers, registry entries, database drivers, network shares, report templates, serial devices and a specific installer sequence.
Keep it reliable
Diagnose startup failures, damaged installations, missing dependencies and environmental changes without changing working business behavior unnecessarily.
Recover knowledge
Inventory projects, forms, modules, controls, database access, integrations and deployment assumptions before the remaining build knowledge disappears.
Modernize deliberately
Separate urgent compatibility work from longer-term replacement. A stable VB6 application can often be improved incrementally while a safer migration path is prepared.
Common VB6 failure patterns
| Symptom | Likely areas to investigate | First evidence to preserve |
|---|---|---|
| Application no longer starts | OCX/COM registration, DLL search paths, permissions, missing configuration, database connectivity | Exact error, event log, installation media, working-machine inventory |
| Runs on one PC only | Undocumented runtime files, registry state, DSNs, mapped drives, locale or 32-bit assumptions | File and registry comparison between working and failing machines |
| Source exists but cannot build | Missing project groups, custom controls, binary-compatible components, type libraries and old SDKs | Complete source tree, original binaries and any surviving development machine |
| Database or device operations fail | DAO/ADO/ODBC providers, credentials, serial settings, timing and vendor-specific protocols | Connection strings, sample data, logs and known-good transactions |
Support, preservation or modernization?
Support and repair are appropriate when behavior is understood, the operational risk is bounded and the application still meets the business need. The goal is a reproducible installation and a diagnosed dependency set.
Preservation matters when original media, source, compilers, controls or hardware are scarce. Preserve a working environment before experimenting. A disk image alone is not enough if databases, peripherals and credentials live elsewhere.
Modernization is justified when operating-system compatibility, unsupported components, security isolation or change demand makes continued repair increasingly fragile. Read the VB6 application modernization guide before treating an automated code conversion as a plan.
How an investigation starts
- Copy source, binaries, installers, configuration, databases and documentation without altering the only working machine.
- Record Windows version, architecture, locale, user privileges, installed controls, DSNs and connected equipment.
- Reproduce the failure or build in a controlled environment and capture evidence rather than repeatedly changing dependencies.
- Map business-critical workflows and identify what cannot be interrupted.
- Choose the smallest safe intervention, then document how to reproduce it.
For continuing operational work, see VB6 legacy application support. Investigate code completeness through source analysis; use application recovery for missing build or deployment assets, the startup diagnostic for launch failures and OCX troubleshooting for identified ActiveX errors.
VB6 systems frequently cross into legacy databases, serial communication and software reverse engineering.
Compatibility diagnostics
For a named native library use missing DLL analysis. Activation identity and interface failures belong in COM troubleshooting, while a failing registration command belongs in registration diagnosis. Assess the combined deployment environment through VB6 runtime on Windows 11.
Runtime error diagnosis
Use the focused guides for error 429, error 53, error 76 and error 91. Database-bound systems should separate data and application change through VB6 database modernization.
Database and serial implementations
Use the focused guides for Access/Jet applications, SQL Server applications, DAO, ODBC and VB6 serial communication.
Focused runtime and integration guides
Diagnose component loading with error 339, trace data conversion through error 13, and isolate provider behavior with ADO troubleshooting. Device-specific work is covered by MSComm troubleshooting and VB6 printer integration.
Recovery and migration paths
Recover architecture through VB6 reverse engineering; choose between staged .NET migration and modern Windows compatibility work. Use startup-crash diagnosis when initialization begins but fails.
For build continuity, see development-environment recovery, the VB6 IDE on modern Windows and installer modernization. Device projects are separated into hardware integration and barcode scanners.
Migration engagement
For technical assessment, proof of concept and phased delivery across code, data, devices and deployment, see VB6 migration services.