Our UPS WorldShip setup has become increasingly unstable over the past few weeks. The environment consists of one LAN Admin computer and two workstations. WorldShip initially crashed mostly during label printing, but it now also crashes while users are simply entering shipment information. Both workstations are affected, and restarting the application only provides temporary relief.
Windows Application logs consistently show a .NET Runtime error, followed by an Application Error and Windows Error Reporting entry. The faulting process is WorldShipTD.exe version 29.0.705.0, the faulting module is wstdDB.dll, and the exception is 0xc0000005, indicating an access violation.
UPS Support reinstalled WorldShip on the LAN Admin computer, but the workstation crashes continued. The WorldShip SQL database runs locally on the LAN Admin computer. We have also noticed that some shipments appear in the end-of-day report but do not appear in the normal shipment history.
The LAN Admin computer has 16 GB of RAM, while the workstations have 32 GB. The workstations run a mix of Windows 10 and Windows 11, and the LAN Admin computer runs Windows 10. Has anyone encountered this combination of wstdDB.dll crashes and missing shipment-history entries? Could the cause be database corruption, a recent WorldShip update, networking or firewall behavior, or something else in the shared database setup?
3 Answers
Firewall or application-allow rules are worth checking if the WorldShip executables cannot communicate correctly with the LAN Admin database. However, since this setup worked for years without recent firewall or Group Policy changes, that seems less likely than a damaged database, failed update, or changed WorldShip component. I would compare the installed versions on all three machines, verify the required WorldShip services and network paths, and have UPS investigate the recurring 0xc0000005 fault against version 29.0.705.0.
The wstdDB.dll fault makes a damaged or inconsistent WorldShip database a strong possibility, especially since some shipments are reaching the end-of-day report but not appearing in history. I would have UPS check the database integrity and review the database logs rather than only reinstalling the client application. Also make sure the database is backed up before attempting repairs. Archiving older shipment data may reduce the workload temporarily, but it would not fix underlying corruption.
WorldShip has become more memory-intensive for some installations, and archiving old shipment records can help with performance. That said, with 16 GB on the LAN Admin system and 32 GB on the workstations, memory alone does not explain the crashes very well. The missing history entries point more toward a database or synchronization problem than a simple workstation resource issue.
That was my concern too. The LAN Admin system has 16 GB and the workstations have 32 GB, so we will focus on checking the shared database and its integrity instead of assuming the workstations are underpowered.