---

Hallo SolidWorks-Anwender,

auch wenn dieses Thema schon ausgiebig diskutiert wurde,
scheint sich die Anzahl der Betroffenen User täglich zu erhöhen.
Ich habe in den vergangenen 14 Tagen an 3 Standorten das Update
auf SolidWorks 2010 SP4.0 durchgeführt und dabei verschiedene
Hardware Bedingungen vorgefunden. Bei allen Anwendern tritt dieser Fehler auf,
und nervt ganz gewaltig. Auch ich habe die Erfahrung gemacht, dass unser Vertrieb
die Sache sehr ernst nimmt, dass ganze aber in Amerika kein Gehör findet.

Schade eigentlich.

Freue mich schon auf SolidWorks 2011

Gruß
anwope

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

---

ich nutze SW 2008 & 2010, da ist doch kaum ein Unterschied  Also freu Dich nicht zu früh auf 2011 

------------------
Gruß Thermo

Take it easy, altes Haus, wer morgens länger schläft, hälts abends länger aus.

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

---

Von was für einem Fehler sprichst du?
oder stehe ich gerade auf dem Schlauch

------------------
...strebe niemals nach den Dingen, die auch dümmeren gelingen.....

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

---

unbekannter_Fehler.PNG

meinst du den Fehler hier?

den hatte ich schon unter sw2009
und unter 2010 (bisher) nur unter simulation

leider nie nachvollziehbar . gr...

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

---

Pic-131.jpg

Ich denke er spricht von diesem Fehler hier --->

Der trat bei uns auch ab und zu mal auf (ab SWX2006) und tut es immer noch, allerdings sehr selten. Bei uns schien das Problem zu sein, daß unsere Bemaßungen in der Vorlage fälschlicherweise auf "Passung" standen, und damit die Maße in allen Zeichnungen und Modellen ebenfalls auf "Passung" standen, auch wenn keine Passungen vergeben wurden.
Klickte man dann auf so ein Maß, kam diese Fehlermeldung. Allerdings nicht reproduzierbar, sonder so alle ein, zwei Wochen mal.

Mittlerweile haben wir das korrigiert, unsere Bemaßungen sind wieder richtig eingestellt und der Fehler taucht nur aller paar Monate mal auf (bei >25 Usern).

Es gab allerdings vor kurzem noch diesen interessanten Thread, vielleicht hilft der ja weiter. Aber bestimmt hast du ihn schon gefunden.

------------------
Gruß,
Stephan

"Optimismus ist lediglich ein Mangel an Informationen"

BOFH

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

---

Hallo anwope,

wir hatten (haben) den auch seit der Umstellung auf die 2010 wieder vermehrt, ich hab manchmal das Gefühl, dass der Fehler gar nicht sooooo unbekannt sein dürfte, da es immer wieder nach einer Versionsumstellung gehäuft auftritt 

Das Ganze scheint mit nicht aktuellen Daten in den nicht aktiven Konfigurationen von Komponenten oder Modellen aus Zeichnungen zu tun zu haben; ich habe mehrere Anwender, die diesen fehler bekommen (und anschließend z.B. das nicht mehr speichern können oder andere Arbeiten nicht mehr durchführen können) wenn z.B. eine Komponente ersetzt werden soll oder in Zeichnungen verschiedenen Konfigurationen derselben Modelle dargestellt werden.

Nicht nur deswegen konvertieren wir z.B. möglichst alle Daten (auch die freiegegebenen) aus dem PDM System und lassen dabei von den Modellen auch alle Konfigurationen durchrechnen. Das kann der Taskplaner übrigens auch, da gibt es bei dem Task zum Konvertieren eine option alle Konfigurationen durchrechnen zu lassen.

ich vermute deiner Anwender haben aber genauso wie die bei uns auch noch eine Menge lokaler daten (oder auf Serververzeichnissen), die nicht konvertiert bzw. aktualisiert sind. Je länger die mit den Daten arbeiten, die verschiedene Konfigs aktualisieren und die konvertietren daten speichern desto seltener kommt zumindest bei uns auch der "Unbekannte Fehler" - ganz weg geht es allerdings nicht.

Ich vermute das Problem auf Seiten SolidWorks ist es das auch nachstellen zu können, denn bei uns ist es in der Regel so, dass nach einem Neustart von SolidWorks dieselben Dokumente bei denselben Aktionen dann funktionieren und den Fehler nicht bringen. Also Reproduzierbarkeit nicht wirklich gegeben.

Unterm Strich kann ich dir sagen, dass du nicht aleline bist, dass es gerade nach einer Versionsumstellung, so lange noch "alte" oder nicht aktuelle Daten rumgeistern, gehäuft auftritt und die Nicht-Reproduzierbarkeit des Fehlers wohl zur schwierigen Lösung wohl beiträgt.

Ciao,
Stefan

------------------
Inoffizielle deutsche SolidWorks Hilfeseite    http://solidworks.cad.de
Stefans SolidWorks Blog

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

---

Guten Morgen an Alle,
wir hatten bis vor kurzen das gleiche Problem (s. Unbekannter Fehler beim editieren von Maßen).
Nach vielen, vielen Versuchen...Telefonaten und Besuchen von unserem Reseller, haben wir für uns eine Lösung/Verschiebung des Problems gefunden.
Das eigentliche Problem war nicht die Voreinstellung auf Passung, sondern nur eine Auswirkung.
Ist Passung eingestellt, versucht SolidWorks eine fit.mdb zu initialisieren. Damit diese initialisiert werden kann, wird ein zusammenhängendes Stück freier Arbeitsspeicher benötigt. Da SolidWorks diesen Arbeitsspeicher aber extrem fragmentiert (scheinbar in Version 2010 deutlich schlimmer...wohl schon für W7 optimiert), fehlt nach einer gewissen Zeit dieses Stück. Dies führt dann zum "Unbekannten Fehler".

Eine bisher sehr gute Lösung ist hier der 3GB-Patch für XP-32 (wir haben 4GB-RAM):
[boot loader]
timeout=5
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional mit 3GB" /fastdetect /3gb /userva=2750 /NoExecute=OptIn
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /NoExecute=OptIn

Als eigentliche Lösung, sollen wir aber auf Win7 64-Bit und 8GB-RAM umsteigen.
Ps. Der "Unbekannte Fehler" erscheint bei der initialisierung aller mdb's (Bohrungsassisten, Abstandsverknüpfungen wenn Passung voreingestellt...)

LG Timo

[Diese Nachricht wurde von Grosser Buba am 11. Aug. 2010 editiert.]

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

---

Hallo zusammen,
erst einmal vielen Dank für die rege Anteilnahme an diesem Beitrag.
Mittlerweile ist einige Zeit vergangen und Dank tatkräftiger Unterstützung durch unseren Support (Fr. Gronert von der SolidLine)
und einer sehr interessanten WEB-Sitzung mit einem indischen Kollegen aus der Supportabteilung von SolidWorks konnte der Fehler
eingegrenzt werden und wurde nun auch offiziell als solcher mit der SPR 578368 bestätigt.
Alle weiteren Details werden nachfolgend beschrieben.

Gruß
anwope

I have now reported SPR 578368, after a continued discussion with the development team. I will attach it to this SR, and you will be informed when this SPR is closed. We have reproduced the problem, and now the diagnosis is on to understand the reason for the memory usage and reserved memory.
I am closing the SR now. The users can use the workaround of /3GB switch as we already discussed.
A permanent solution would be moving to X64 environment.

Zur Erklärung mal ein Ausschnitt einer Mail, die ich vorher bekommen habe:

After the testing and further discussions with the dev team, I learnt that this problem occurs due to a memory 'reservation' when a genuine lack of memory case happens. That is, when the process nears its maximum limit of memory consumption (On X32, it will be 2GB by default, and 3GB with /3GB switch), then certain memory is reserved in heaps for future use that may be reused when we open a new file, but that memory is unavailable for new allocations - and this is when the problem occurs. If any database connection (Hole wizard, or dimension with Fit, Toolbox etc) is attempted at this point by the same process, it will be denied due to the lack of memory until the process is closed. This is specific to the process - that is, when this problem occurs in SolidWorks, if you open another instance of SolidWorks (if enough memory is available, with the help of page file), then you can insert Hole Wizard in that instance of SolidWorks without any problem.

---------------
The memory limitation behavior is being diagnosed by the development team. We are now doing the testing in order to find if there is any way to release the memory (though this is done by the memory manager in OS).
The current workaround is to enable /3GB switch (Yes, even for computers that have 2GB RAM - since the processes use virtual memory, and hence a process can go till ~3GB if you have sufficient RAM+page file) and add sufficient  page file. This will increase the memory limit per process, so the process will have additional memory before it reaches the limit - which should help in most of the cases. However, if the process reaches the ~3GB limit also, then the error occurs.
Let me know if you need any further information about the virtual memory, and the 'per process' limit of virtual memory on X32 systems. Here's a good link:
http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx

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

---

Hallo Anwope,

Danke für Deine Ausführliche Beschreibung. Ich habe ebenfalls dieses Problem nur stehe ich zusätzlich noch unter einem anderen Problem siehe hier, deshalb habe ich den 3GB Switch nicht gestzt

Könntest Du Rückmeldung geben wenn die Meldung kommt dass das gefixt wurde?

gruß Heiko

------------------
CAD.de treffen in Stuttgart, nicht nur für ProblEme am 16.11 Flying Ship Echterdingen.

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

---

Hallo Heiko,

laut Aussage vom SW Support soll die SPR 578368 - SPR for the diagnosis of high resource consumption in SolidWorks- in 2012 A1 gefixt sein. Hoffen wir das Beste.

Zunächst hieß es zwar, es gäbe keine Lösung, da es ein Speichermanagmentproblem von Windows unter 32 bit sei, aber in SW2012 scheint sich da was zu tun.

Nachfolgend sind einige allgemeine Informationen zur Speicherauslastung durch SolidWorks angegeben.
(Stammt aus einer Lösung der SW Knowledgebase): 
Die Speicherauslastung durch SolidWorks steigt während der Verwendung des Programms aus verschiedenen Gründen: Speicher wird sowohl durch Daten als auch durch Programmroutinen belegt.  Konstruktionsroutinen (Bibliotheksdateien) werden bedarfsabhängig in den Speicher geladen, der belegte Speicherplatz wird nach der Verwendung jedoch nicht wieder freigegeben.  Dies ist logisch, da eine Bibliotheksroutine sehr häufig im Programm verwendet wird, weil Konstrukteure normalerweise wiederholt dieselben Aktivitäten ausführen.  Dadurch wird die Ladezeit für das Hauptprogramm optimiert und die Speicherauslastung insgesamt minimiert, weil nur die Module geladen werden, die der Anwender benötigt.  Als Folge davon ist die Speicherauslastung beim Schließen von SolidWorks, nach dem Öffnen einiger Dokumente und Ausführen von Bearbeitungsaktivitäten, immer höher als beim Starten von SolidWorks. 
Ein weiteres Merkmal der Speicherauslastung ist die Speicherfragmentierung.  Während der Verwendung weist SolidWorks Speicherplatz in fortlaufenden Blöcken einer bestimmten Größe zu.  Nach der Verwendung wird der Speicher zur erneuten Belegung freigegeben.  Auf Grund dieser Art der Speicherzuweisung und -freigabe kann ein fortlaufender Speicherblock von kleineren Speicherzuweisungen genutzt werden, wodurch der Speicherbedarf des Programms sehr hoch ist, jedoch kleine Fragmente nicht zugewiesenen Speichers entstehen.  Diese Speicherblockfragmente sind einzeln jedoch zu klein, als dass sie für die meisten erforderlichen Programmtasks genutzt werden können. 
SolidWorks hat Tools zur internen Erfassung der nicht zugewiesenen Fragmente entwickelt, damit in diesem fragmentierten Speicher keine Speicherverluste auftreten. Deshalb steigt die Speicherauslastung durch SolidWorks, wenn ein Arbeitsablauf mehrere Male wiederholt wird. Wegen der Speicherfragmentierung pendelt sich die Gesamtspeicherauslastung des Programms nach häufiger Wiederholung desselben Arbeitsablaufs ein. 
Die Untersuchung von Speicherdefragmentierungsprozessen durch SolidWorks-Entwickler hat ergeben, dass sie zu Instabilität führen und deshalb nicht von SolidWorks unterstützt werden.  Durch Experimentieren hat SolidWorks festgestellt, dass die größtmögliche Speicherauslastung dann erreicht und die Nachricht, dass SolidWorks nicht genügend Speicher zuweisen könne, normalerweise angezeigt wird, wenn 75 % des theoretisch verfügbaren Speichers belegt ist. 
Der theoretisch verfügbare Speicher wird vom Betriebssystem gesteuert und entspricht dem installierten Speicher plus Auslagerungsdateigröße.  Vorausgesetzt, dass der installierte Speicher plus Auslagerungsdatei groß genug ist, liegt der maximale thread-adressierbare Speicher bei folgenden Werten:
Windows XP 32-Bit                        2 GB,
Windows XP 32-Bit mit 3-GByte-Switch      3 GB,
Windows XP 64-Bit mit SolidWorks 32-Bit  4 GB,
Windows XP 64-Bit mit SolidWorks 64-Bit  8 TB.

Es wurde festgestellt, dass im Task-Manager nicht die korrekte Auslastung angegeben ist. 
Intern verwendet SolidWorks die Maßangabe "Seiten/s", die im Leistungsüberwachungstool von Windows für den Prozess SldWorks.exe angeben ist.

Aber wie Anfangs schon geschrieben scheint sich da in 2012 A1 was getan zu haben (bzw. zu tun) :-)

Viele Grüße,
Selkie

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

---

Danke für die Meldung Selkie,

ich bin seit letzter Woche auf 64bit W7 unterwegs und bin begeistert. Persönlich habe ich den Eindruck daß von 2009 auf 2010 im Bereich Speichermanagement bzw. reservierung seitens SWX sehr wohl etwas gemacht wurde (vielleicht auch für die Zukunft W7?) weil zuvor auf 2009 konnte ich wirklich mehr in den Speicher pressen

Bei mir war es jetzt gegen ende so schlimm (ca. 10 mal am Tag ohne 3GB switch) daß ich umgestellt habe. W7 64bit Lizenz hatte ich eh schon da, nur die Peripherie und weitere Software hat damit Probleme weshalb unser Admin nur zögerlich zugestimmt hatte(das alte Zeug läuft jetzt auf einer virtuellen Maschine).

Glaubt mir es ist für mich jetzt eine ganz andere Welt endlich wieder ordentlich arbeiten zu können, ohne ständig SWX zu schließen und Dateien neu zu laden. Selbst mit nur 4GB Ram hatte ich null Probleme, habe aber auf 8GB erweitert.

gruß Heiko

------------------
Umstieg auf 64bit OS, was meint ihr?
Plauderthread
Umfrage

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