Nikon CNX 2.2.4 EOOM Bug - Servicefälle gesucht

[vdaiker]

Das ist sicher ein Bug von CNX, weil selbst als 32 Bit Applikation muesste es eigentlich moeglich sein, bis 4 GByte Speicher zu verwalten, zumindest theoretisch unter einem 64 Bit Betriebssystem.

Das ist nicht richtig. 32 Bit Anwendungen unter Windows können nur 2 GB verwalten. Es gab da einen Schalter wie man manche (z.B. Catia) auf 3 GB bringen kann. Die genauen Zusammenhänge müsste dir aber einer der Profis erklären.

Die Zahl von 3 GB hat auch nix damit zu tun, dass W32 oft nur 3,x GB bereitstellt. Das hat was mit dem Adressraum zu tun der unterhalb von 4GB eingeblendet wird. Es gibt da auch keine feste Grenze. Ich hab zw. 2,8 und 3,5 GB schon alles gesehen.

OK, dann ist ja mehr oder weniger klar was da passiert. CNX braeuchte mehr als 2 GByte und das geht nicht. Und es ist voellig Wurscht wieviel Speicher physikalisch vorhanden ist.

Weshalb allerdings eine 64 Bit Windows Version nicht wenigstens 4 GByte RAM pro Applikation zur Verfuegung stellen kann verstehe ich nicht.

Ich fuerchte dieses Problem wird sich erst mit einer 64 Bit Variante von CNX loesen lassen, denn selbst wenn es so einen "Trickschalter" fuer CNX gaebe, man wuerde diese Grenze halt nur ein bischen verschieben.

[Arjay]

versuch mal (auf eigene Verantwortung ) das: bcdedit /set IncreaseUserVA 3072

Mit: bcdedit /deletevalue IncreaseUserVa kann mans wieder zurücksetzen!!

Bei Microsoft
und in diesem Forum steht was drüber.

Ich würde den Bereich mal Schrittweise (je 128MB) erhöhen.
Denn eigentlich sollte Win bei zuendegehen des Speichers damit beginnen auszulagern.

Danke für die Links, das werde ich mir mal ansehen.

Allerdings stehe ich solchen Dingen relativ reserviert gegenüber, denn eine sauber konzipierte Softwareapplikation sollte nicht so geschrieben sein, dass man den Rechner an sie anpassen muss - es sollte anders herum laufen. Die meisten Anwender sind schließlich keine Anwendungsspezialisten (und wollen es berechtigterweise auch nicht sein). Eine Software, die - wie CNX2 - in großen Stückzahlen auf dem Markt eingesetzt wird, sollte vom Hersteller ganz klar auf den Einsatz in normal konfigurierten Rechnern (Standard-Betriebssysteminstallationen) ausgerichtet sein. Ist sie das nicht, dann ist etwas mit der Software nicht in Ordnung.

Insofern würde ich so was nur machen, wenn (a) sich die Sache rückgängig machen lässt, und (b) wenn ich damit sinnvolle Infos gewänne, mit denen Nikon seine Software selbst verbessern könnte.

Frage: Ist Dein System was Updates angeht Up2date? Vor allem die NET-Geschichte würde ich mal ins Auge fassen.
Vielleicht mal die Windows-Update-Seite besuchen!

Mein Rechner nutzt die automatische Windows-Updatefunktion für regelmäßige Updateläufe an den normalen Microsoft Patch-Tagen. Wenn das ausreicht, um den Rechner up-to-date ist, dann ist meiner auf dem aktuellen Stand. Das müsste sich auch auf .NET erstrecken, denn dabei handelt es sich doch um eine normale Windows-Komponente, oder?

[yaggi]

Nun, eigentlich sollte Win bei zu Ende gehen des physikalischen Speichers, bzw, bereits vorher, damit beginnen auf Platte auszulagern! Dafür gibts den Mechanismus ja.
Prinzipiell muss es KEIN Bug von NX sein. Da NX ja auf .NET aufsetzt, bzw. mit diesem Framework entwickelt wird, vermute ich den Fehler eher dort, vielleicht auch die Kombination von Beidem
Ich denke nicht, dass sich jemand der eine Bildbearbeitung entwickelt, grundlegend um die Speicherverwaltung kümmert bzw kümmern muss. Dafür hat man vorgefertigte Bibliotheken!
Es könnte natürlich sein, dass NX NUR mit der mitgelieferten .NET-Version sicher läuft und sich durch ein Update Desselbigen besagter Fehler einschleicht.

Ein Versuch wäre folgendes Szenario wert:
1. In einer Virtuellen Machine Timo's Umgebung nachbauen
2. NX 2.2.4 mit der beigefügten .NET-Umgebung (oder ist die gar nicht mit auf CD?) installieren!
3. Testen

Wobei man natürlich mit der Einschränkung leben muss, dass man (zumindest in VBox) keine beliebige Hardware nachbilden kann

[yaggi]

...
Mein Rechner nutzt die automatische Windows-Updatefunktion für regelmäßige Updateläufe an den normalen Microsoft Patch-Tagen. Wenn das ausreicht, um den Rechner up-to-date ist, dann ist meiner auf dem aktuellen Stand. Das müsste sich auch auf .NET erstrecken, denn dabei handelt es sich doch um eine normale Windows-Komponente, oder?

Die Patch-Tage betreffen meines Wissens nur Sicherheitslücken! Einfach mal mit dem IE auf die Updateseite gehen und Rechner durchsuchen lassen!

Oder so ein Programm installieren, das erledigt so was automatisch!

[Arjay]

Ein Versuch wäre folgendes Szenario wert:
1. In einer Virtuellen Machine Timo's Umgebung nachbauen
2. NX 2.2.4 mit der beigefügten .NET-Umgebung (oder ist die gar nicht mit auf CD?) installieren!
3. Testen

Hm - Du bist wohl vom Fach. Was Du da aber schreibst, verstehe ich nicht so recht.

Ich habe das CNX2 Update von Nikon herunter geladen. Da war sicherlich kein MS .NET Update dabei.

Was würdest Du mir nun ganz konkret empfehlen? BS updaten über die MS Updateseite? An den Systemeinstellungen für die Speicherzuweisung herum schrauben?

Wenn ich Dich richtig verstanden habe, dann dürfte es aktuell das Beste sein, wenn ich überprüfe, ob MS .NET auf dem neuesten Stand ist. Geht das über den Besuch auf der MS Updateseite für Windows Vista?

[vdaiker]

Das .NET Geraffel ist nicht Bestandteil von NX2, es ist nur eine Vorraussetzung und wird bei Bedarf vom Netz gezogen und installiert.

Aber wenn doch Roland Recht hat, und eine 32 Bit Applikation unter Windows nicht mehr als 2 GByte Speicher zugewiesen werden kann, dann ist es doch voellig Wurscht, ob dieser Speicher aus dem RAM oder von der Auslagerungsdatei kommt, wenn die 2 GByte voll sind ist Schluss, basta. Da nutzt alles Gefrickele nichts, es sei denn man umgeht die 2GByte Grenze oder MS bringt ein Update was eben mehr als 2 GByte zuweisen laesst.

Ich kenne mich zwar nicht mit Windows aus, aber als Softwareentwickler kann ich es mir nicht anders vorstellen.

[zappa4ever]

Das .NET Geraffel ist nicht Bestandteil von NX2, es ist nur eine Vorraussetzung und wird bei Bedarf vom Netz gezogen und installiert.

Aber wenn doch Roland Recht hat, und eine 32 Bit Applikation unter Windows nicht mehr als 2 GByte Speicher zugewiesen werden kann, dann ist es doch voellig Wurscht, ob dieser Speicher aus dem RAM oder von der Auslagerungsdatei kommt, wenn die 2 GByte voll sind ist Schluss, basta. Da nutzt alles Gefrickele nichts, es sei denn man umgeht die 2GByte Grenze oder MS bringt ein Update was eben mehr als 2 GByte zuweisen laesst.

Ich kenne mich zwar nicht mit Windows aus, aber als Softwareentwickler kann ich es mir nicht anders vorstellen.

Richtig erkannt. Da bringt auch die Auslagerungsdatei nix mehr. Andererseits läuft PS mit deutlich größeren Dateien seit Jahren problemlos - auch als 32 Bit.

Der Schalter von yaggi ist der, den ich meinte. Er kann aber auch neg. Auswirkungen haben - auch auf andere Programme bzw. die Systemstabilität. Zudem müsste geklärt werden, ob CNX damit überhaupt zurecht kommt.
Ich bin nur interessierter Mitleser (Comp. Foren und c't) und kein wirklicher Experte. Grundsätzlich halte ich aber auch das Verhalten von CNX nicht für koscher. Und nat. sollten die Programmierer nicht nur Bibliotheken verwenden sondern auch bei solchen die Peripherie (also Speicher usw.) im Auge haben. Dass andere das können (PS) zeigt nur dass es eben geht. Den Endanwender interessiert es ehrlich gesagt nicht die Bohne ob das an CNX oder .NET liegt. Der zahlt Geld für die Software und damit sollte sie unter halbwegs normalen Bedingungen auch funktionieren.

Was ich jetzt aber nicht verstanden habe. Tritt der Fehler nur bei Timo auf, oder haben den auch andere ?

[vdaiker]

Was ich jetzt aber nicht verstanden habe. Tritt der Fehler nur bei Timo auf, oder haben den auch andere ?

Nun ja, ich vermute mal, wenn andere dasselbe machen wuerden haetten sie auch diesselben Probleme. Timo arbeitet mit NX wie ich es noch nie gesehen habe, mit mehreren Ebenen und Masken und so, das ist was fuer Fortgeschrittene, ich bin eher Anfaenger. Auch hat Timo gescannte 16 Bit TIF Dateien, die er mit NX bearbeitet und diese dann als NEF speichert.
Ausserdem haette mein Rechner nur insgesamt 2 GByte, wenn ich an diese Grenze stossen wuerde, dann wuerde mein Rechner wahrscheinlich unendlich langsam werden wegen dem dauernden Auslagern.

Vielleicht benutzt PS zumindest in Teilen andere Speicherverwaltungsbibliotheken und ist deshalb resistent gegen dieses Speicherproblem. Das Programm kostet ja auch eine Stange mehr und mit Sicherheit entwickeln da ein paar Leute mehr dran rum als an NX. Aergerlich ist es aber trotzdem, weil, wenn ich Timo richtig verstanden habe, koennte man vieles aus PS auch mit NX erledigen, wenn da nicht solche fundamentalen Probleme waeren.

[Arjay]

Sehr sonderbar - ich habe jetzt mal auf meinem Vista-Rechner alle BS-Komponenten updaten lassen. Also alles, was bei Microsoft an Updates angeboten wird. Einschließlich Windows Live (was ich eigentlich nicht brauche, da der Rechner im Alltagsbetrieb gar nicht ins Internet gehen soll). Bei dem ganzen Windows Live Klimbim sind nämlich die MS .NET Updates in einem Untermenü versteckt!

Nun habe ich als Test eines meiner kritischen Bilder erneut bearbeitet und die RAM-Belegung per Taskmanager untersucht. Und siehe da, plötzlich steigt die RAM-Belegung nicht mehr so dramatisch an! Was noch eigenartiger ist - lade ich eine meiner früheren problematischen NEF Dateien, die auf dem Stand des letzten "Engine out of Memory" Fehlers sind, dann steht die RAM-Belegung auf dem gleichen Wert wie vor dem .NET Update! Wenn ich das gleiche Bild auf einem früheren Versionsstand lade und die letzten Arbeitsschritte neu mache, die zuletzt zu dem "EooM" Fehler führten, dann beträgt der Wert für die RAM-Belegung nun weniger als die Hälfte dessen, was früher zum Fehler führte. Das verstehe mal einer...

Es sieht jedenfalls jetzt so aus, dass das .NET Update tatsächlich die Lösung des Problems war.

Nun sollte Nikon seinen Usern aber wenigstens mal klar sagen, dass das .NET Update gezielt installiert werden muss, weil es ja nicht im Rahmen der normalen BS-Updates installiert wird. Nikon sollte also einen speziellen Update-Link für .NET anbieten! Das .NET Update wird bei Microsoft nämlich nicht gesondert für Windows Vista angeboten.

Das einzige .NET Updateangebot bei Microsoft ist dieses hier:

http://www.microsoft.com/downloads/deta ... laylang=en

Allerdings ist das V 3.5 und stammt vom November 2008. Ich habe irgendwo mal gelesen, dass die aktuelle .NET Version 4.0 ist ... Aber wo man die separat (und nicht als Teil des Windows Live Updates) her bekommt, konnte ich noch nicht ermitteln.

[StefanM]

Ich glaube nicht, daß es was mit 32-bit/64-bit und RAM zu tun hat

Ich hab den Fehler auf meinem Desktop (8GB und 64-bit Win7) gelegentlich, auf meinem Notebook (4GB und 32-bit Win7) nicht.

Beim Werkeln hab ich mal den Taskmanager im Vordergrund und geschaut - weder bei x64 noch bei x86 wird meine NX2-Datei annähernd 2 GB groß. Vorher scheint ausgelagert zu werden und werte um die 1,5GB waren auf beiden Systemen das Maximum.

@Timo: Wie äußert sich bei Dir der Fehler? Ich hab wenn das Problem auftritt folgenden Ablauf:

* 1-5 Bilder lassen sich normal bearbeiten und speichern
* irgendwann geht es dann los, daß ich umfangreich bearbeitete Bilder nicht speichern kann, NX2 schmiert ab
* es verschlimmert sich, NX2 friert dann irgendwann schon beim Bearbeiten ein
* erst ein Rechnerneustart bringt dann wieder Ruhe, manchmal länger, manchmal kürzer

Wenn NX2 hängt warte ich nicht stundenlang auf Fehlermeldungen im Klartext, sobald "keine Reaktion" o.ä. bzw. das milchige Overlay kommt, kille ich den Task.

Bis vor Kurzem hatte ich weder unter Vista x64 noch Win7 HP x64 Probleme, erst ein lizenztechn. notwenig gewordener Umstieg (eher Neuinstallation ) auf Professional brachte mir das ein.

IMHO ist das ein eindeutiges Zeichen, daß es a) kein generelles Windowsproblem und b) auch kein generelles NX2 Problem sein kann. Das deutet für mich schwer auf eine unglückliche Konstellation hin, die man weder leicht isolieren noch mal eben so beheben kann

Meine derzeitige Lösung scheint eh LR3 zu heißen