| | | Gut zu wissen: Hilfreiche Tipps und Tricks aus der Praxis prägnant, und auf den Punkt gebracht für SOLIDWORKS | | | | Nahe an industriellen Realbedingungen |
Autor
|
Thema: API - Totalabsturz von SW bei Makroanwendung (2501 mal gelesen)
|
Andi Beck Ehrenmitglied V.I.P. h.c. Konstrukteur
Beiträge: 2572 Registriert: 02.10.2006 Firma: SW 2023-4.0 + PDM Prof. Windows 10 Pro 64bit, i9-11900 32 GbRAM, Quadro P2200 Home: SW 2022-5.0 Passungstabelle von Heinz Windows 11 Pro 64bit, i7-12700K, 32 GbRAM, GeForce GTX 1050Ti Samsung C34H892, 3440x1440 Pixel
|
erstellt am: 14. Jan. 2015 00:15 <-- editieren / zitieren --> Unities abgeben:
Hallo, ich habe einen unregelmäßigen Totalabsturz von SW2014, wenn ich 2 bestimmte Makros aufrufe, in denen jeweils die gleiche Routine verwendet wird. Die beiden Makros haben hier im Forum einen eigenen Thread. Solid-open-PDF http://ww3.cad.de/foren/ubb/Forum2/HTML/027029.shtml Assembly-Print-Drawings (bei Verwendung der Option "PDF-Zeichnungen kopieren") http://ww3.cad.de/foren/ubb/Forum2/HTML/022358-2.shtml In beiden Makros wird eine Routine verwendet, die ich von hier habe. http://www.vbarchiv.net/tipps/tipp_126-ermitteln-aller-dateien-eines-ordners-unterordners.html Dieser unregelmäßige Absturz erfolgt an 4 Rechnern unter Windows 7, 64 Bit und SW2014. Der Absturz erfolgt meist, wenn SW bereits eine Weile in Verwendung ist, evtl. auch andere Makros bereits verwendet wurden. Wenn SW nach dem Absturz erneut gestartet wird, laufen beide Makros sauber durch, bei Verwendung der selben Dateien etc., egal ob nur eine oder mehrere Dateien geöffnet sind, völlig unerklärlich. Wenn das Makro sauber durchläuft, kann ich diesen Vorgang x Mal wiederholen, kein Absturz. Da Totalabsturz, komme ich nicht automatisch in den Debuggingmodus und könnte somit die empfindliche Codestelle identifizieren. Durch eingebaute MsgBoxen habe ich herausgefunden, bei welcher Routine SW abstürzt. z.B.: Call MsgBox("Beginn der Datenerfassung im PDF-Ordner", vbSystemModal, "Information") FindFile PdfPath, True, "*.pdf", Dateien Call MsgBox("Ende der Datenerfassung im PDF-Ordner", vbSystemModal, "Information") Die erste MsgBox kommt immer, die zweite nur, wenn das Makro durchläuft. Die Routine FindFile hat die Aufgabe, einen bestimmten Windowsordner nach PDF-Dokumenten zu durchsuchen und das Ergebnis in einem Array zwischenzuspeichern. Es ist übrigens egal, ob der Pfad ein Netzwerkpfad oder ein lokaler Ordner ist. Dieser Ordner nebst Unterordner ist über 3 GB groß, und enthält mehrere tausend Dokumente. Beide Makros habe ich hier in der aktuellen Version angehängt. Dies betreffende Routine habe ich als Auszug in der txt-Datei angehängt. Hat jemand eine Idee, wovon diese Abstürze kommen können? Warum tut es mal und mal nicht? Wie könnte ich in der Fehleranalyse weiter vorgehen? Für sachdienliche Hinweise wäre ich mehr als nur erfreut. Wenn der Fehler gefunden wird, werden die Makros natürlich in ihren eigenen Beiträgen aktualisiert. Grüße, Andi
------------------ Hast du kein Problem? Such dir eins. ( Und löse es ) Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
StefanBerlitz Guter-Geist-Moderator IT Admin (CAx)
Beiträge: 8756 Registriert: 02.03.2000 SunZu sagt: Analysiere die Vorteile, die du aus meinem Ratschlag ziehst. Dann gliedere deine Kräfte entsprechend und mache dir außergewöhnliche Taktiken zunutze.
|
erstellt am: 14. Jan. 2015 09:12 <-- editieren / zitieren --> Unities abgeben: Nur für Andi Beck
Hallo Andi, solche Art der Abstürze sind doch unsere Liebsten, da weiß man dann doch immer, dass das mit der binären Logik doch nicht so ganz stimmig sein kann Ich persönlich argwöhne, dass es etwas mit dem Hin-und-her-dimensionieren der Felder, dem Umpacken und den Doevents zu tun haben könnte, das ist aber mehr ein Gefühl im Hinterkopf als das ich den Finger drauf legen könnte. Ich benutze eine ähnliche, aber etwas anders aufgebaute Funktion für diese Aufgabe von http://www.vb-tec.de/fndfiles.htm ; da wird das nicht mit Feldern gemacht, sondern mit einer Collection. Auch das auswerten funktionier etwas anders, auch wenn dieselben Win-API-Calls benutzt werden. Ansonsten hilft wohl nur ein Logging innerhalb der FindFile Prozeduren um das weiter einzugrenzen. Vermutlich ist es irgendwas in den Win-APIs oder dem Memoryhandling beim Umpacken (da wird die Error-Behandlung wohl vorher kurz ausgeschaltet), sonst sollte die VBA-Umgebung das abfangen können. Sollte, hätte, müsste - die besten Voraussetzungen für ein gelungenes Debugging Ciao, Stefan ------------------ Inoffizielle deutsche SolidWorks Hilfeseite http://solidworks.cad.de Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
THSEFA Mitglied Konstrukteur/CAD-Admin
Beiträge: 1141 Registriert: 27.11.2002 SWX 2020 SP5.0 Premium Windows 10 Pro 64Bit Citrix VM Intel(R) XEON(R) Gold 6146 CPU @ 3.20GHz 24 GB Ram<P>Windows 10 Pro 64Bit
|
erstellt am: 14. Jan. 2015 09:29 <-- editieren / zitieren --> Unities abgeben: Nur für Andi Beck
Hallo Andy, Schön zu sehen, dass du immer noch fleißig am Codeoptimieren bist! Ich denke, es ist die Menge an Dokumenten, die dir Probleme bereitet. Liegt das Zeug auch noch auf einem Server, brauchst du nur mal eine kleine Unterbrechung der Verbindung, um deine Probleme zu potenzieren. (ja, das mit dem Verbindungsabbruch ist bei uns schon mehrfach vorgekommen und hat mich fast in den Wahnsinn getrieben!!) Geduld und Fleiß sind wie immer der Schlüssel zu Erfolg. Aber da braucht man sich ja um dich nicht zu sorgen!! ------------------ Viele Grüße, THSEFA "Nichts ist so hart wie das Leben! Wenn man sagt, was man denkt, muss man mehr als alles geben!..." Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Torsten Niemeier Ehrenmitglied V.I.P. h.c. Maschinenbau Ingenieur
Beiträge: 3682 Registriert: 21.06.2001 "ZUSE I.36", 8 BIT, 32 Lämpchen, Service-Ölkännchen "ESSO-Super", Software: AO auf Kuhlmann-Parallelogramm-Plattform ** CSWP 04/2011 ** ** CSWE 08/2011 **
|
erstellt am: 14. Jan. 2015 15:26 <-- editieren / zitieren --> Unities abgeben: Nur für Andi Beck
Ein Versuch wäre vielleicht wert, das Redirection des 64bit-Systems im Makro vor den Findfirst, Findnext usw. kurzfristig zu deaktivieren. Ich gehe zwar davon aus, dass Du nicht in den Systemordnern suchst, aber wer weiß... Hättest Du die Möglichkeit, das Makro noch auf einem 32-bit zu testen, um zu sehen, ob der Fehler dort auch auftritt? Gruß, Torsten Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Andi Beck Ehrenmitglied V.I.P. h.c. Konstrukteur
Beiträge: 2572 Registriert: 02.10.2006 Firma: SW 2023-4.0 + PDM Prof. Windows 10 Pro 64bit, i9-11900 32 GbRAM, Quadro P2200 Home: SW 2022-5.0 Passungstabelle von Heinz Windows 11 Pro 64bit, i7-12700K, 32 GbRAM, GeForce GTX 1050Ti Samsung C34H892, 3440x1440 Pixel
|
erstellt am: 14. Jan. 2015 17:26 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen, und danke für eure Beiträge. Also, der zu untersuchende Pfad ist auf dem Server (Netzwerkpfad, WindowsServer 2012, 64-bit) auf Laufwerk D, kein Systemordner. FindFile "\\SERVER\D-Server\0-Projekte\Zeichnungen", True, "*.pdf", Dateien Ich habe diesen Ordner aber auch Testweise lokal kopiert und dort ist das gleiche Verhalten festzustellen. FindFile "C:\1Arbeitsverzeichnis\Zeichnungen", True, "*.pdf", Dateien Torsten, ich kann leider nicht mehr unter 32-bit testen. Wie und wo du das Redirection deaktivieren möchtest, ist mir noch nicht klar. Ich werde mal untersuchen, welche Dateiinformationen bei der Abfrage ich ausblenden kann, da ich sie nicht wirklich benötige. Ich werde mich auch mal an Stefans Routine ranmachen und die testen. Aber das dauert evtl. noch ein wenig. Grüße, Andi ------------------ Hast du kein Problem? Such dir eins. ( Und löse es ) Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Luechinger Mitglied Ingenieur + CAD-Admin
Beiträge: 71 Registriert: 30.07.2008 Win 7 64bit HP Elitebook 8740W 8 GB Ram Solidworks 2012 SP4 (64bit) ProE WF4 M140 (64bit) Stools 2012
|
erstellt am: 14. Jan. 2015 17:42 <-- editieren / zitieren --> Unities abgeben: Nur für Andi Beck
Hallo Andi Ja solche nicht direkt reproduzierbaren Fehler sind sauschwer zu finden. Ich habe mal folgendes erfolgreich gemacht zum Eingrenzen: Im möglicherweise fehlerhaften Code habe ich alle paar Zeilen eine Zahl in ein externes Textfile schreiben lassen. (erst 1 dann mit 2 überschreiben, dann mit 3 überschreiben, etc.) Wenn dann der Fehler auftritt schaust Du in das Textfile und weisst anhand der Nummer wo im Code der Absturz war. Mit Msgboxen geht das auch aber dann kann man das Makro nicht einfach normal benutzen. So konnte ich alle Benutzer drauflos lassen und musst nicht ewig zu testzwecken selber laufen lassen. Gruss David Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Torsten Niemeier Ehrenmitglied V.I.P. h.c. Maschinenbau Ingenieur
Beiträge: 3682 Registriert: 21.06.2001 "ZUSE I.36", 8 BIT, 32 Lämpchen, Service-Ölkännchen "ESSO-Super", Software: AO auf Kuhlmann-Parallelogramm-Plattform ** CSWP 04/2011 ** ** CSWE 08/2011 **
|
erstellt am: 14. Jan. 2015 18:13 <-- editieren / zitieren --> Unities abgeben: Nur für Andi Beck
|
Andi Beck Ehrenmitglied V.I.P. h.c. Konstrukteur
Beiträge: 2572 Registriert: 02.10.2006 Firma: SW 2023-4.0 + PDM Prof. Windows 10 Pro 64bit, i9-11900 32 GbRAM, Quadro P2200 Home: SW 2022-5.0 Passungstabelle von Heinz Windows 11 Pro 64bit, i7-12700K, 32 GbRAM, GeForce GTX 1050Ti Samsung C34H892, 3440x1440 Pixel
|
erstellt am: 15. Jan. 2015 20:17 <-- editieren / zitieren --> Unities abgeben:
Zitat: Original erstellt von Andi Beck:
Ich werde mal untersuchen, welche Dateiinformationen bei der Abfrage ich ausblenden kann, da ich sie nicht wirklich benötige.
Hallo, das hat leider auch nichts gebracht, obwohl es zuerst danach aussah. 6 von 8 Dateiinformationen konnte ich unterdrücken, sodass beim Umpacken weniger Gefahr drohte. Nun habe ich bei Solid-open-PDF diese problematische Routine kpl. rausgeschmissen und dafür diese hier genommen. http://www.vb-tec.de/findfile.htm (Verzeichnis durchsuchen) Diese Seite wird über Stefans Link erreicht. Jetzt ist dieses Makro deutlich schlanker und es scheint momentan stabil zu sein. Diese Variante ist bei diesem Makro auch völlig ausreichend, da hier nur ein einzelnes PDF-Dokument gesucht wird. Bei Assembly-Print-Drawings möchte ich diese Variante aber nicht nehmen, da dort auch schon mal mehrere 100 PDF-Dokumente und mehr gesucht werden. Da macht es durchaus Sinn, einmalig den ganzen Fundus auszulesen, zwischenzuspeichern und anschließend dann auszuwerten. Da denke ich, wird Stefans Link evtl. die geeignete Variante sein. Werde ich bei nächster Gelegenheit dann auch noch Testen. Danke euch erst mal für die hilfreichen Tipps, ich halte euch auf dem Laufenden. Grüße, Andi ------------------ Hast du kein Problem? Such dir eins. ( Und löse es ) Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Andi Beck Ehrenmitglied V.I.P. h.c. Konstrukteur
Beiträge: 2572 Registriert: 02.10.2006 Firma: SW 2023-4.0 + PDM Prof. Windows 10 Pro 64bit, i9-11900 32 GbRAM, Quadro P2200 Home: SW 2022-5.0 Passungstabelle von Heinz Windows 11 Pro 64bit, i7-12700K, 32 GbRAM, GeForce GTX 1050Ti Samsung C34H892, 3440x1440 Pixel
|
erstellt am: 19. Jan. 2015 19:24 <-- editieren / zitieren --> Unities abgeben:
Hallo, am WE habe ich mich mit Stefans Collection auseinandergesetzt, kannte ich bisher noch nicht. Wer daran Interesse hat, kann sich diese Seite anschauen, wird schön erklärt. http://www.office-loesung.de/ftopic429248_0_0_asc.phpIch habe diesen Code in Assembly-Print-Drawings eingebaut und zum laufen bekommen. http://www.vb-tec.de/fndfiles.htm Meine Codeauszüge findet ihr wieder in der beiliegenden Textdatei, so auch das kpl. Prg.. Leider verhält es sich wieder wie bereits oben beschrieben mit Abstürzen von SW, mal tut es, mal nicht. Zu Hause ist mir aber etwas aufgefallen. Dort habe ich nur einen Arbeitsspeicher von 4 GB. Habe ich eine Baugruppe geladen und mein verwendeter Arbeitsspeicher beträgt ca. 3,5 GB, kann das Makro durchlaufen. Bei 3,8 GB ging nichts mehr und beiliegende bekannte Fehlermeldung kommt. Nun hoffte ich auf den Rechner im Geschäft, wo ich 16 GB Arbeitsspeicher habe. Aber da bekam ich einen Absturz bei einer Baugruppe mit ca. 8 von 16 GB verwendetem Speicher. Also die Vermutung mit Speicherüberlauf hat sich so nicht bestätigt. In meinem Kopf geistert nun die Geschichte mit Unload rum, wovon ich aber keine Ahnung habe. Ich lese hier nur hin und wieder davon. Kann es damit irgend wie zu tun haben, und wenn ja, wo soll ich welchen Code einbauen? Dies mal für den Moment. Grüße, Andi
------------------ Hast du kein Problem? Such dir eins. ( Und löse es ) Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Torsten Niemeier Ehrenmitglied V.I.P. h.c. Maschinenbau Ingenieur
Beiträge: 3682 Registriert: 21.06.2001 "ZUSE I.36", 8 BIT, 32 Lämpchen, Service-Ölkännchen "ESSO-Super", Software: AO auf Kuhlmann-Parallelogramm-Plattform ** CSWP 04/2011 ** ** CSWE 08/2011 **
|
erstellt am: 20. Jan. 2015 18:20 <-- editieren / zitieren --> Unities abgeben: Nur für Andi Beck
|
Andi Beck Ehrenmitglied V.I.P. h.c. Konstrukteur
Beiträge: 2572 Registriert: 02.10.2006 Firma: SW 2023-4.0 + PDM Prof. Windows 10 Pro 64bit, i9-11900 32 GbRAM, Quadro P2200 Home: SW 2022-5.0 Passungstabelle von Heinz Windows 11 Pro 64bit, i7-12700K, 32 GbRAM, GeForce GTX 1050Ti Samsung C34H892, 3440x1440 Pixel
|
erstellt am: 20. Jan. 2015 19:07 <-- editieren / zitieren --> Unities abgeben:
Zitat: Original erstellt von Torsten Niemeier: Hattest Du die Redirection mal testweise deaktiviert? Immerhin ist ja auch Dein neuer verbauter Codeschnipsel nicht mehr der jüngste...
lach Hallo Torsten, nein, noch nicht. Das wäre das nächste, was ich angehen möchte. Die lange englische Seite hat mich bisher dazu gebracht, es hintanzustellen. Aber jetzt werde ich mich da wohl einlesen müssen, grins. Auch Davids Vorschlag finde ich Klasse, aber mit dem externen Schreiben in eine Textdatei muss ich auch erst noch nachforschen. Ein Schritt nach dem anderen. Danke für deine Nachfrage. Grüße, Andi ------------------ Hast du kein Problem? Such dir eins. ( Und löse es ) Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Torsten Niemeier Ehrenmitglied V.I.P. h.c. Maschinenbau Ingenieur
Beiträge: 3682 Registriert: 21.06.2001 "ZUSE I.36", 8 BIT, 32 Lämpchen, Service-Ölkännchen "ESSO-Super", Software: AO auf Kuhlmann-Parallelogramm-Plattform ** CSWP 04/2011 ** ** CSWE 08/2011 **
|
erstellt am: 20. Jan. 2015 19:20 <-- editieren / zitieren --> Unities abgeben: Nur für Andi Beck
Hallo Andi. Nimm doch einfach den Schnipsel aus dem 2. Link: zusätzliche API-Dekl.: Private Declare Function Wow64DisableWow64FsRedirection Lib "Kernel32" (ByRef oldvalue As Long) As Boolean Private Declare Function Wow64RevertWow64FsRedirection Lib "Kernel32" (ByVal oldvalue As Long) As Boolean zusätzlich Variablen: Dim ret As Boolean Dim oldvalue As Long Dann vor jedes FindFirst, FindNext usw.: ret = Wow64DisableWow64FsRedirection(oldvalue) und dahinter wieder einschalten: Wow64RevertWow64FsRedirection oldvalue Gruß, Torsten
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Andi Beck Ehrenmitglied V.I.P. h.c. Konstrukteur
Beiträge: 2572 Registriert: 02.10.2006 Firma: SW 2023-4.0 + PDM Prof. Windows 10 Pro 64bit, i9-11900 32 GbRAM, Quadro P2200 Home: SW 2022-5.0 Passungstabelle von Heinz Windows 11 Pro 64bit, i7-12700K, 32 GbRAM, GeForce GTX 1050Ti Samsung C34H892, 3440x1440 Pixel
|
erstellt am: 21. Jan. 2015 08:38 <-- editieren / zitieren --> Unities abgeben:
Danke Torsten, ich hab das gestern Abend noch getestet und leider bekomme ich die gleichen Abstürze. Ist doch zum Mäuse melken, aber ich gebe noch nicht auf. Grüße, Andi ------------------ Hast du kein Problem? Such dir eins. ( Und löse es ) Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Andi Beck Ehrenmitglied V.I.P. h.c. Konstrukteur
Beiträge: 2572 Registriert: 02.10.2006 Firma: SW 2023-4.0 + PDM Prof. Windows 10 Pro 64bit, i9-11900 32 GbRAM, Quadro P2200 Home: SW 2022-5.0 Passungstabelle von Heinz Windows 11 Pro 64bit, i7-12700K, 32 GbRAM, GeForce GTX 1050Ti Samsung C34H892, 3440x1440 Pixel
|
erstellt am: 22. Jan. 2015 18:48 <-- editieren / zitieren --> Unities abgeben:
So, ich habe jetzt eine externe Protokolldatei mitschreiben lassen, sodass man genau sieht, an welchem Punkt sich das Makro aufhängt. Im ersten Protokoll sieht man die Dateistruktur mit Unterordnern und einzelnen Dateien, wenn das Makro durchläuft. Ich habe nur den Anfang des Protokolls eingetragen, weil in Echt da einige tausend Zeilen drin sind. Im Zweiten Protokoll sieht man, das sich das Makro bereits am Anfang dieser Routine aufhängt. Es wird noch nicht einmal eine einzige Datei erfasst. Bei jedem Absturz sieht das Protokoll genau so aus. In der dritten Datei ist die Routine mit den eingefügten Codezeilen um das Protokoll zu erstellen. Evtl. mag sich das mal jemand anschauen und kann sich daraus einen Reim machen, warum das Makro immer hier abstürzt, wenn es den abstürzt. Ich habe zumindest keine Erklärung dafür. Grüße, Andi
------------------ Hast du kein Problem? Such dir eins. ( Und löse es ) Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
KMassler Ehrenmitglied V.I.P. h.c. CAD Admin + Mädchen für Alles...
Beiträge: 2675 Registriert: 06.11.2000 SolidWorks Start 1999 ** CSWP 01/2008 ** ------------------ Zuletzt beruflich: - SWX2020 SP5; - SAP/PLM+ECTR; - DriveWorks Pro; - Programmierung: VBA, aktuell Visual Studio 2022/VB.Net ------------------ ab 2024 (privat): Onshape und anderes
|
erstellt am: 23. Jan. 2015 09:42 <-- editieren / zitieren --> Unities abgeben: Nur für Andi Beck
|
Andi Beck Ehrenmitglied V.I.P. h.c. Konstrukteur
Beiträge: 2572 Registriert: 02.10.2006 Firma: SW 2023-4.0 + PDM Prof. Windows 10 Pro 64bit, i9-11900 32 GbRAM, Quadro P2200 Home: SW 2022-5.0 Passungstabelle von Heinz Windows 11 Pro 64bit, i7-12700K, 32 GbRAM, GeForce GTX 1050Ti Samsung C34H892, 3440x1440 Pixel
|
erstellt am: 17. Feb. 2015 21:00 <-- editieren / zitieren --> Unities abgeben:
Hallo, nur der Vollständigkeit halber. Ich habe nun auch in Assembly-Print-Drawings die Routine wie bereits in Solid-open-PDF eingebaut. Zur Erinnerung hier: http://www.vb-tec.de/findfile.htm (Verzeichnis durchsuchen) Nach einigen Tagen mit Tests auf mehreren Rechnern kann ich momentan von einer Stabilität sprechen. Keine regelmäßigen Abstürze mehr. Jetzt hoffe ich nur, das diese Routine nicht eine übermäßige Festplattenaktivität auslöst, sondern die internen Dateiverzeichnisse von Windows anzapft. Kann dies jemand bestätigen? Jedenfalls die enorme Schnelligkeit dieser Funktion lässt darauf schließen. Ich werde jetzt das Makro im eigenen Beitrag aktualisieren. http://ww3.cad.de/foren/ubb/Forum2/HTML/022358-2.shtml Nochmals Danke an alle Helfer. Grüße, Andi ------------------ Hast du kein Problem? Such dir eins. ( Und löse es ) Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
| Anzeige.:
Anzeige: (Infos zum Werbeplatz >>)
|