I am experiencing a consistent crash issue with Automation Studio 4.12.5.95 when attempting to open a specific project. The project was last successfully edited approximately one month ago using the exact same software and hardware configuration currently in use.
Here is a summary of the issue:
Automation Studio consistently crashes during the opening of this particular project, generating both an internal Automation Studio crash report and an entry in the Windows event log.
Other projects edited around the same time or afterwards open without issues.
A previous version of this specific project opens correctly without any problems.
The differences between the working and problematic versions of the project involve only minor changes to the safe configuration.
I have already tried deleting the project’s temporary folder, but the issue persists.
Given that technical support is currently unavailable, I would greatly appreciate any insights or experiences from the community that could help identify the nature of this issue or potential solutions.
I was experiencing a consistent crash issue with Automation Studio 4.12.5.95 when attempting to open a specific project. After a personal preliminary analysis of the Automation Studio crash report, I decided to try the only solution that appeared useful: replacing the file indicated as “corrupted” with the corresponding file from a working version of the project. This was an empirical attempt based on the simple observation that if the report flagged the file as unreadable (which it indeed was, compared to the same file from a functional project), correcting this issue might resolve the crash.
The attempt seems successful, as the project now opens correctly without Automation Studio displaying any anomalies. However, now my concern is understanding the severity of this error—specifically, why the corruption of a 1 kB file could entirely prevent Automation Studio from opening the project.
Files : default.brk , default.tch , default.tr
Any insights or similar experiences would be greatly appreciated.
I can’t explain in detail how it works, but at least I know that those files are used by the source level debugger for storing breakpoints, lists, and so on (for example, the default.tch file contains variable lists from the debugger watch).
I can’t swear, but I can imagine that if a debugger session was opened (or at least a task was in monitor mode) when closing the project, after reopening this project AS automatically will try to load the last debugger configuration like it is with any other project window that was opened, too.
And if there’s a problem with accessing that files, AS could crash in a very first stage of opening this project (which is not good of course and should be handled by an expection handler for example, I agree!).
From my personal experience of using AS 4.12.x, I would recommend to use the latest (at the moment) version 4.12.7.113 (link to _SP file). I have had version 4.12.6.106 installed in Windows 11 and AS crashed often in certain situations. Upgrading to version 4.12.7.113 solved the problem!
I’m not sure that such an upgrade would help you, but perhaps it is worth trying…
As @s4gia I would recommend to use AS4.12.6 or higher, I would recommend the lastest (AS4.12.7).
Based on revision of AS4.12.7:
There is a correction about a crash with Watch window (QCAS-812: Automation Studio Watch crashes) combine with @alexander.hefner informations that could be the root cause of the crash.
Additionally, updating to version “7” of Automation Studio 4.12 currently doesn’t seem feasible, as the upgrade path from version 5 to 6 appears unclear or unavailable. Furthermore, the upgrade file to version 7 explicitly states the necessity of having version 6 installed first. This situation raises doubts about why there isn’t a simple incremental upgrade of just a few megabytes, instead requiring downloads of several gigabytes. Has anyone else encountered this issue or can provide clarification?
