We had in the past also crashes of Uniface. We had opened a support call for it and got an message with info how to setup the crash handling by Uniface. https://courtheyn.be/Uniface/UnifaceCrashHandle.txt

very interesting, thanks for sharing, Uli

From an older Crash I found an email from Daniel Iseli: ----------------------- Wir können allerdings noch versuchen einen Dump mit dem Diagnose Tool DebugDiag (www.debugdiag.com) von Microsoft zu erstellen. Hier ist eine Kurzanleitung für DebugDiag: "Installieren Sie einfach DebugDiag, führen Sie "DebugDiag 2 Collection" aus, klicken Sie auf "Add Rule", wählen Sie "Crash", wählen Sie "A specific process", geben Sie uniface. exe für "Selected Process" (oder den Namen des Prozesses, den Sie überwachen möchten) ein, setzen Sie "Action type for unconfigured first chance Exceptions" (siehe "Unconfigured First Chance Exceptions" auf dem Bildschirm "Advanced Confuguration (Optional)") auf "Log Stack Trace" wählen Sie Erweiterte Einstellungen: Exceptions, klicken Sie auf Next, um zum Bildschirm "Select Dump Location and Rule Name" zu gelangen, und auf Next (To "Activate the rule now") und beenden Sie den Vorgang. Mit den oben vorgeschlagenen Einstellungen sammelt DebugDiag 10 Dumps für jede Art von Ausnahme (Exceptions), die zu einem Absturz führen kann. Und DebugDiag erstellt auch eine Protokolldatei für den Prozess, die nützlich sein kann (sie zeigt unter anderem die Anzahl und Art der First Chance Exception, die vom Prozess geworfen werden). Zusätzlich können Sie auch Full PageHeap aktivieren (was uns ein wenig mehr Info geben könnte): Wählen Sie "Enable Full PageHeap" auf dem Bildschirm "Configure PageHeap Flags "." ------------------- This will lead us to : ============= Exception Information UMSW!UWMMSW10+3955WARNING - DebugDiag was not able to locate debug symbols for \\umsw.dll, so the information below may be incomplete. In uniface__PID__14712__Date__08_20_2018__Time_10_25_25AM__960__Second_Chance_Exception_C0000005.dmp the assembly instruction at umsw!UWMMSW10+3955 in \\\\S33BFSENTW1\\bfs$\\Uniface\\Test\\common\\bin\\umsw.dll from Uniface B.V. has caused an access violation exception (0xC0000005) when trying to read from memory location 0x00000000 on thread 0 Module Information Image Name: \\\\S33BFSENTW1\\bfs$\\Uniface\\Test\\common\\bin\\umsw.dll Symbol Type: Export Base address: 0x00905a4d Time Stamp: Thu Mar 29 16:28:48 2018 Checksum: 0x00000000 Comments: COM DLL: False Company Name: Uniface B.V. ISAPIExtension: False File Description: Uniface 9 ISAPIFilter: False File Version: 9.7.04 G415 Managed DLL: False Internal Name: VB DLL: False Legal Copyright: Copyright © 2018 Uniface B.V. All rights reserved. Loaded Image Name: umsw.dll Legal Trademarks: Mapped Image Name: Original filename: Module name: umsw Private Build: Single Threaded: False Product Name: Uniface Module Size: 804 KBytes Product Version: 9.7.04 G415 Symbol File Name: umsw.dll Special Build: & ============== In the detail-Trigger of "MASKE.MENUE" is a call to a Global Proc that starts a new Form : newinstance /attached P_FORM, P_FORM, "MODALITY=NON-MODAL" if ( $status = 0 ) if ( P_PARAMETER = "" ) activate P_FORM.EXEC() if ($status < 0 ) activate P_FORM.EXEC("") if ($status < 0 ) activate P_FORM.EXEC("","") if ($status < 0 ) activate P_FORM.EXEC("","","") if ($status < 0 ) activate P_FORM.EXEC("","","","") if ($status < 0 ) activate P_FORM.EXEC("","","","","") else activate P_FORM.EXEC(P_PARAMETER) endif endif Entering the Formname in "MASKE.MENUE" and pressing the RETURN-Key leads to the Crash. Whereelse pressing a Button will not crash : $prompt = MASKE.MENUE macro "^DETAIL"

Lauterbach said The same Component crashes in only one Configaration. ... 

Hi Lauterbach, Question/Hint: - what is differentiating the crashing config from others non-crashing configs? - very large parameters exchanged? - try to generate from your code a custom log file to reduce the code area to be furtherly investigated. Gianni

The point where the system crashes is when a testform "TEST_1" is called : activate "TEST_1".exec() In the exec-Trigger is just an edit statement, so no special code is executed at this time. After pressing a Button some testcode is executed.   The configs differ only in different Logicals and an different database-user.   As mentioned : If you use $proc_tracing = 1 the program is not crashing!   This is not the first time where I recogniced that using proc_tracing or debugger changes the behavior of uniface.   Norbert

Hi Norbert It's a "normal" behaviour of software: Using debug or tracing will prevent an application from crashing :-) >https://en.wikipedia.org/wiki/Race_condition "Problems occurring in production systems can therefore disappear when running in debug mode, when additional logging is added, or when attaching a debugger, often referred to as a "Heisenbug". It is therefore better to avoid race conditions by careful software design rather than attempting to fix them afterwards." Back to your problem: Try to use NEWINSTANCE before ACTIVATE : Still crashing? Put some PUTMESSss into INIT and EXEC-trigger: If it's still chrashing, then you can determine if the crash occour before or after INIT Go to all FMT/DFMT-triggers and replace any proc code by ";" If avail, use a external debugger (like VisualStudio) and run UNIFACE.EXE in debug mode. Okay, you got no information where in your code is the problem, but may, which DLL is the one in question: Is it database problen, a windows problem,... A last thought: Export the component, clear and delete in UnifAce and import it back Ingo