---

Hallo zusammen.

Hätte folgende Frage:

Problem:
Wenn ProE abstürzt geht alles im Arbeitsspeicher verloren. Kein automatisches Speichern anderer Teile/Zeichnungen/usw. vor Beendigung des Programms.

Frage:
Gehört das so oder kann das Thema über Einstellungen erschlagen werden?

Version:
WF4

mfg
Michl

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Moin,

ist so und bleibt wohl auch so...

------------------
Beste Grüße,
Max

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Es gibt da das ein oder andere Zusatzprogramm, mit dem man eine Autosicherung einstellen kann.
Aber ich kenne persönlich keinen Anwender, der (wenn er das Programm zur Verfügung hat) das dann auch verwendet.

Denn wenn man bei ProE automatisch sichert, wird entweder das aktuelle Fenster (also auch Skizzen, etc), alle Fenster,oder nur ausgewählte Dateitypen gespeichert.
Ist man also in einer kleinen Skizze, hat nur Teile und Baugruppen freigeschaltet, kann es bei großen Baugruppen durchaus vorkommen, das Du für ein paat Sekunden in der Skizze nicht weiterarbeiten kannst.

Unter Creo 1.0 habe ich auch noch keine Veränderung zu diesem Punkt gefunden.

Gruß
Meike

------------------
Neu hier?  Verwundert über manche Antworten? 

Wichtige Links für noch mehr Spaß im WBF:  Richtig Fragen - Nettiquette - Suchfunktion - System-Info - 7er-Regel - Unities

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

 

Zitat:

---

Original erstellt von abdafür:
Problem:
Wenn ProE abstürzt geht alles im Arbeitsspeicher verloren. Kein automatisches Speichern anderer Teile/Zeichnungen/usw. vor Beendigung des Programms.

---

Im April saß ich auf der Hannovermesse am PTC-Stand mit dem Geschäftsführer unseres deutschen PTC-Dienstleisters und einem Channel-Manager von PTC zusammen, um (mal wieder) den unendlichen Pro/E-Absturzhorror bei uns zu debattieren, und da kam genau diese Frage auf den Tisch. Konkret ging es sowohl um die im Moment des Absturzes bearbeiteten Konstruktionsdaten des Anwenders als die Ermittlung der Absturzursache durch Export eines Dumps.

Der Geschäftsführer regte sich mächtig darüber auf, daß Pro/E bis heute nicht in der Lage ist, bei einem Absturz einen Dump herauszuschreiben, aus dessen Inhalt ein PTC-Entwickler sofort feststellen könne, in welcher Routine und an welcher Adresse welche Speicherverletzung stattgefunden habe, etwas, was bei IBM-Programme angeblich schon vor zwanzig Jahren Standard war. Der PTC-Channel-Manager konnte nur hilflos mit den Schultern zucken.

[Diese Nachricht wurde von Callahan am 13. Jul. 2011 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Wer möchte wirklich Modelldateien eines abstürzenden Prozesses sichern.
- Der aufgetretene Fehler kann die Daten korrupieren und zu Problemen führen die man nicht gleich merkt.
- Eine regelmäßige Sicherung ist sicher das deutlich sicherere Mittel

Hier ein paar Informationen zum Thema Dump Datei, was da drin steht und was das einem Entwickler tatsächlich hilft....

Wenn das Betriebsssystem in einem Prozess (also dem xtop.exe) eine schwerwiegende Ausnahme feststellt, dann hat dieser Prozeess noch die Chance eine Dumpdatei zu schreiben bevor er vom Betriebssystem entsorgt wird.

Diese Dumpdatei ist die aktuelle Momentaufnahme zum Zeitpunkt des Absturzes. Man kann also die aktuelle Unterroutine die gerade ausgeführt wird, die Funktion die diese aufgerufen hat etc. einsehen (man nennt das auch Call stack). Dazu kommt die aktuelle Belegung von "einigen" Programmvariablen.

Mit diesen Informationen kann man manchmal (wenn der Fehler nicht genau diese Informationen überschrieben hat) feststellen, wo das aufgetretene Problem zum Absturz des Prozesses geführt hat. In der Regel ist der Fehler aber schon sehr viel früher aufgetreten und läßt sich durch diese Momentaufnahme nicht mehr feststellen.

Die Fehlersuche mit einer Dumpdatei ist oftmals eine ziemlich steinige Angelegenheit und meist nur dann sinnvoll, wenn sich der Fehler nicht an einem Beispiel reproduzieren läßt.

Zitat:

---

Original erstellt von Callahan:
Im April saß ich auf der Hannovermesse am PTC-Stand mit dem Geschäftsführer unseres deutschen PTC-Dienstleisters und einem Channel-Manager von PTC zusammen, um (mal wieder) den unendlichen Pro/E-Absturzhorror bei uns zu debattieren, und da kam genau diese Frage auf den Tisch. Konkret ging es sowohl um die im Moment des Absturzes bearbeiteten Konstruktionsdaten des Anwenders als die Ermittlung der Absturzursache durch Export eines Dumps.

Der Geschäftsführer regte sich mächtig darüber auf, daß Pro/E bis heute nicht in der Lage ist, bei einem Absturz einen Dump herauszuschreiben, aus dessen Inhalt ein PTC-Entwickler sofort feststellen könne, in welcher Routine und an welcher Adresse welche Speicherverletzung stattgefunden habe, etwas, was bei IBM-Programme angeblich schon vor zwanzig Jahren Standard war. Der PTC-Channel-Manager konnte nur hilflos mit den Schultern zucken.

---

Vermutlich ist ein Channel-Manager nicht gerade der geignetste Anprechpartnet für eine Frage mit solchem technischen Tiefgang. Es gibt aber durchaus die Möglichkeit in Pro/E gewisse informationen im Falle eines Absturzes rauszuschreiben und diese an PTC zu senen (auto_trasceback = yes). Ich würde aber empfehlen zu versuchen den Fehler zu reproduzieren und dann die Traildatei mit Modellen an die Hotline zu senden.

Was ein IBM Programm schon vor zwanzig Jahren vermutlich auf einer AS/400 unter UNIX als Dumpdatei ausgeben konnte ist im Kern sicher ähnlich wie das was man heute mit einem Windows Dumpfile erreichen kann. Allerdings sie die Programme derart komplizierter geworden, dass der Rückschluss sehr viel schwieriger geworden ist.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

  

Zitat:

---

Original erstellt von AchimSchoen:
Vermutlich ist ein Channel-Manager nicht gerade der geignetste Anprechpartnet für eine Frage mit solchem technischen Tiefgang. Es gibt aber durchaus die Möglichkeit in Pro/E gewisse informationen im Falle eines Absturzes rauszuschreiben und diese an PTC zu senen (auto_trasceback = yes).

---

Wir schicken seit rund 14 Monaten wöchentlich nicht nur bis zu 20 Traceback-Dateien an den PTC-Support, sondern auch die beteiligten Pro/E-Modelle, sämtliche verfügbaren Traildateien, alle std.out's, alle std.err's, alle app.logs, alle uwgm.logs sowie die redirect_proe.log (wird von Pro/E rausgeschrieben, wenn man die psf-Datei manipuliert).

Mit welchem Erfolg? Auf einer Telefonkonferenz vergangene Woche mit PTC und unserem PTC-Dienstleister bekamen wir tatsächlich von dem beteiligten PTC-Mann eröffnet, dass die meisten dieser Log-Dateien von der PTC-Entwicklung noch gar nicht ausgewertet worden seien, da man dort die Absturzprobleme anderer (größerer) Kunden als kritischer ansähe. Der PTC-Mann wortwörtlich zu uns: "Sie haben kein Stabilitätsproblem." Ich enthalte mich da einmal eines passenden Kommentares.

Demnächst werden wir auch noch zusätzlich Microsoft ADPlus auf den am meisten betroffenen Clients installieren, um bei einfrierenden Sessions Speicherdumps zu erzeugen. Ob's was bringt?

Nachtrag: Die config-Option auto_traceback kann man seit Wildfire 4.0 M180 auch auf "always" statt auf "yes" stellen, erspart dem Anwender einen Bestätigungs-Klick.

[Diese Nachricht wurde von Callahan am 13. Jul. 2011 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Callahan:
[B]   Wir schicken seit rund 14 Monaten wöchentlich nicht nur bis zu 20 Traceback-Dateien an den PTC-Support, sondern auch die beteiligten Pro/E-Modelle, sämtliche verfügbaren Traildateien, alle std.out's, alle std.err's, alle app.logs, alle uwgm.logs sowie die redirect_proe.log (wird von Pro/E rausgeschrieben, wenn man die psf-Datei manipuliert).

... da man dort die Absturzprobleme anderer (größerer) Kunden als kritischer ansähe. Der PTC-Mann wortwörtlich zu uns: "Sie haben kein Stabilitätsproblem." Ich enthalte mich da einmal eines passenden Kommentares.

---

14 Monate mit 20 Traceback Dateien pro Woche macht überschlagen 1200 Eingaben an die Hotline und schraubt den Bearbeitungsaufwand wohl in Richtung Mannjahre. Wenn das kein generelles Problem ist und die Anzahl der Arbeitsplätze nicht nicht besonders hoch (was ich beides natürlich nicht weiß), dann würde ich PTC verstehen, wenn sie das Problem nicht mit höchster Priorität angehen.

Falls sich die Probleme irgendwie kategorisieren lassen, würde ich sie mal direkt hier ansprechen. Evtl. hat jemand schon eine Lösung.

Falls die Probleme generell bei unterschiedlichsten Situationen vorkommen, wäre es ratsam Pro/E auf einem anderen Rechner mit möglichst wenigen anderen Software Komponenten zu installieren und evtl. auch mal (falls möglich ) eine andere Wochenversion zu probieren.

Allgemein ist die Wahrscheinlichkeit bei PTC berücksichtigt zu werden deutlich höher wenn man wenige Calls öffnet und die bei Bedarf auch mal eskaliert, als wenn man sie mit Anfrage überhäuft.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von AchimSchoen:
... Allgemein ist die Wahrscheinlichkeit bei PTC berücksichtigt zu werden deutlich höher wenn man wenige Calls öffnet und die bei Bedarf auch mal eskaliert, als wenn man sie mit Anfrage überhäuft.

---

Die alten Hasen dieses Forums wissen, dass Callahan jemand ist, der sich mit der Eskalation von Calls auskennt und auch sonst nichts unversucht lässt, um die Fehler zu beseitigen.
Aber der Kampf gegen Windmühlen ist im Vergleich mit der Auseinandersetzung mit der PTC-Hotline ganz leicht zu gewinnen. Leider.

------------------
Gruß
Udo                 Keine Panik, Du arbeitest mit Pro/E! Und Du hast cad.de gefunden! 

Neu hier?     Verwundert über die Antworten?    Dann schnell nachfolgende Links durchlesen. 
• Richtig Fragen • Nettiquette • Suchfunktion • System-Info • Pro/E-Konfig • 7er-Regel      • Unities

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von AchimSchoen:
Allgemein ist die Wahrscheinlichkeit bei PTC berücksichtigt zu werden deutlich höher wenn man wenige Calls öffnet und die bei Bedarf auch mal eskaliert, als wenn man sie mit Anfrage überhäuft.

---

Das kann ich auch unterschreiben.
Aber bei alten Daten und Problemen damit (Abstürze) häufen sich in letzter Zeit Antworten, dass das ein singuläres Problem der konkreten Dateien sei und damit kein weiterer Handlungsbedarf bestehe.
Dieses Argument kann man eigentlich nur durch eine größere Anzahl von ähnlichen Problemen entkräftigen

------------------
Servus    
Alois

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

 

Zitat:

---

Original erstellt von AchimSchoen:
14 Monate mit 20 Traceback Dateien pro Woche macht überschlagen 1200 Eingaben an die Hotline und schraubt den Bearbeitungsaufwand wohl in Richtung Mannjahre.

---

Es gibt auch Phasen mit über zehn Abstürzen pro Tag. Wenn sich diese Abstürze dann auch noch auf einige wenige Anwender konzentrieren, macht das die Sache besonders unangenehm.

 

Zitat:

---

Falls die Probleme generell bei unterschiedlichsten Situationen vorkommen, wäre es ratsam Pro/E auf einem anderen Rechner mit möglichst wenigen anderen Software Komponenten zu installieren und evtl. auch mal (falls möglich ) eine andere Wochenversion zu probieren.

---

Nett gemeint, aber das haben wir ALLES schon vor Monaten bis zum gehtnichtmehr rauf- und runterdekliniert: Hardware, Betriebssystem, Virenscanner,  Netzwerk, Überprüfung der config-Optionen, Austausch-Workstation, zigfacher Wechsel der Wochenversionen, der Grafikkartentreiber, der Maustreiber...wir haben wirklich alles durch. Das einzige, was PTC und Dienstleister in den Griff bekommen haben, waren die Abstürze, die sich eindeutig nicht Pro/E selbst sondern den verwendeten Toolkit-Applikationen zurordnen ließen. Der Rest ist Schweigen.

 

Zitat:

---

Allgemein ist die Wahrscheinlichkeit bei PTC berücksichtigt zu werden deutlich höher wenn man wenige Calls öffnet und die bei Bedarf auch mal eskaliert, als wenn man sie mit Anfrage überhäuft.

---

Die Calls bei PTC eröffnen nicht wir, sondern unser PTC-Dienstleister, da wir formal von seiner Hotline und nicht von PTC direkt betreut werden. Allerdings sind wir über diesen Punkt ohnehin schon lange hinaus. Auf Grund der Brisanz der Situation findet bereits wöchentlich eine Telefonkonferenz zwischen PTC und unserem PTC-Dienstleister statt. Hört sich nett an, so als würde PTC auch wirklich alles daran setzen, das Problem bei uns zu lösen. Mehr als ein paar hübsche Excel-Diagramme mit den Absturzstatistiken  ist jedoch bislang dabei nicht herausgekommen.

Und auch, wenn's einige nicht mehr hören (bzw. lesen) wollen und können: Ich werde nicht müde, immer wieder den Vergleich mit der bei uns eingesetzen Simulations-Software heranzuziehen. Und zwar, weil sich die Unternehmens-Konstellation so ähnelt: Großes Mutterhaus in den USA, das die Software programmiert, dazu ein kleiner, aber sehr agiler und fähiger Dienstleister in Deutschland, der das System verkauft, wartet, Consulting, Hotline-Support und Schulungen anbietet. Auch hier gibt's Bugs, Abstürze, Probleme...gerade erst letzte Woche haben wir einen richtigen Höllen-Bug in der Temperaturberechnung von Umformvorgängen entdeckt. Aber jetzt kommt eben der alles entscheidende Unterschied: Obwohl wir bei der Simulations-Software nur ein Kunde mit zwei Lizenzen sind (im Gegensatz zu Pro/E, wo es weit über zwanzig sind), dauert es im Normalfall nicht mehr als 24 Stunden nach der Meldung eines Problems, bis wir entweder eine Lösung oder einen praktikablen Workaround plus den Termin des endgültigen Fix in der Software haben.

Dieses Beispiel zeigt mir immer und immer wieder, daß die Katastrophe PTC nicht als gottgegeben und unveränderlich hinzunehmen ist. Es geht eben auch anders.

[Diese Nachricht wurde von Callahan am 14. Jul. 2011 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP