Deskmodder.de

Manny hat geschrieben: 28.12.2019, 15:36

an der Position habe ich bei der 2004 aber "nur" eine SRUDB.dat

mal sehen was passiert wenn ich diese lösche (Systembackup habe ich ja zur Not )

also bei der einzigen *.dat die ich da habe passiert absolut gar nix, wenn ich die lösche wird keine neue erstellt, System läuft so wie vorher auch (incl. der leeren Liste im Taskmanager unter App-Verlauf mit dem Hinweis auf den 19.12.)

- vermute mal das es (bei mir) auch was damit zu tun hat das ich ohne "Systemwiederherstellung" arbeite
( genanntes Modul ist deaktiviert - hab ja Acronis )

EDIT:

falsche Vermutung - nach Aktivierung der Systemwiederherstellung bleibt das genannte Verzeichnis trotzdem komplett leer
( teste jetzt mal ein Inplace mit originaler ISO )

Neustart hast Du ausgeführt? Weil ansonsten passiert da nichts. Gerade erneut versucht, selbes Ergebnis.

Gut, jetzt habe ich mal alle Dateien gelöscht, werden nach Neustart ebenfalls alles wieder neu erstellt, aber in der 1909 keine Änderung beim Task Manager. Die Tabelle {d10ca2fe-6fcf-4f6d-848e-b2e99266fa89} wird nicht neu erstellt. In der 2004 ist die Tabelle aber sofort wieder da.

Auch scheint sich in der 2004 der Dienst "Diagnoserichtliniendienst (DPS)" für die *.dat zu interessieren. Der greift da mind. 1x die Stunde darauf zu. In der 1909 ist das nicht der Fall. Da scheint sich außer mir niemand für die Datei zu interessieren.

Kann also sein, dass da noch ein weiterer Dienst oder Prozess streikt. Ist bloß schwierig, dieses Geflecht zu entflechten.

---

Ach so, vergessen zu erwähnen. Die meisten *.dat und *.edb Dateien sind im ESE Format. Die kann man mit diesem kleinen Tool öffnen und desen Inhalt betrachten:

https://www.nirsoft.net/utils/ese_database_view.html

Editieren ist da nicht möglich, aber ich glaube, das will man auch nicht wirklich.

@DK2000
"Neustart hast Du ausgeführt? Weil ansonsten passiert da nichts. Gerade erneut versucht, selbes Ergebnis."
→ hatte ich selbstverständlich gemacht - es wurde ja auch keine neue dat geschrieben / angelegt

Bei mir mit der 2004 hat es sich nach Inplace erledigt - App-Verlauf ist wieder da ( mit Datum von heute )

im genannten Verzeichnis sind jetzt auch ( wie bei moinmoin ) log-Dateien , betreffende dat Datei und *.jrs-Dateien

Ja, gehe ach mal davon aus, dass sich das bei mir auch mittels Inplace Upgrade beheben lässt. Dennoch würde mich interessieren, was der Grund dafür ist.

DK2000 hat geschrieben: 28.12.2019, 16:32 Ja, gehe ach mal davon aus, dass sich das bei mir auch mittels Inplace Upgrade beheben lässt. Dennoch würde mich interessieren, was der Grund dafür ist.

interessiert mich eigentlich auch wieso weshalb / warum

mal sehen ob es ( bei mir ) wieder "ausfällt" wenn ich das System (windows.old) bereinige und meine (eigentlichen) Systemeinstellungen setze bzw. überprüfe ob sich da was durch das Inplace geändert hat

DK2000 hat geschrieben: 28.12.2019, 15:54 ...
Auch scheint sich in der 2004 der Dienst "Diagnoserichtliniendienst (DPS)" für die *.dat zu interessieren. ...

ich denke DA ist "des Pudels Kern" - bin zwar noch am bereinigen / komprimieren aber es kann gut möglich sein das dieser Dienst (bei mir) deaktiviert war ( über DISM++ ) - teste ich aber noch

___________________________________________________________________________________________________________________________________________
ein weiterer Test wäre die Möglichkeit diesen Dienst zu deaktivieren - dann aber komplett Insider beenden und mit lokalem Konto zu arbeiten

Test erfolgreich bei mir

- Diagnoserichtliniendienst (DPS) deaktiviert → App Verlauf funktioniert nicht

- Diagnoserichtliniendienst (DPS) aktiviert → App Verlauf funktioniert

Inplace Upgrade mit der 1909 hat nicht geholfen.

OK, dann speilt der "Diagnoserichtliniendienst (DPS)" da eine wichtige Rolle.

DK2000 hat geschrieben: 28.12.2019, 17:37 Inplace Upgrade mit der 1909 hat nicht geholfen.

mit originaler oder "modifizierter" ISO ?

Extra frische ISO aus dem UUP Dunp erstellen lassen. Keine eigenen Modifikationen.

OK, was den Dienst angeht, wenn ich die Debug Protokolle aktiviere und den Dienst neu starte, kommt folgendes:
In der 2004 kommen diese Fehler nicht.

Also doch wie im allerersten Post von dir ?

"Was habe ich jetzt schon wieder kaputt gemacht in Windows 10 Pro 1909 (18363.535):"



erstelle mir gerade selber eine 1909, dauert ja fast "Ewigkeiten" , mal sehen ob es mit Clean-Install anders ist

Nein, nicht wie im ersten Post. Das Datum hat sich geändert. Steht jetzt auf 28.12.2019. Aber das war es auch schon.

App-Verlauf bleib leer und der Dienst protokolliert Fehler (s. weiter oben).

meinte dabei eher den Satz "Was habe ich jetzt schon wieder kaputt gemacht..."

ich teste das mal (wenn ISO fertig ist, hab ja eigentlich selber kein 1909 mehr) - erst in VM und dann auf (für solche Zwecke) freie SSD

Ok, nach einem Neustart kam von dem Dienst jetzt etwas Neues in der Ereignisanzeige:
Ok, warum kann man das nicht verständlicher ausdrücken. Das wäre vermutlich langweilig.

Das einzig verständliche: "Das Diagnosemodul hat keine Lösung festgelegt."

Und "Error = 183" steht wohl für "Cannot create a file when that file already exists."

Wäre es jetzt zu viel verlangt, noch dazuzuschreiben, um welche Datei es geht. Dann könnte ich sie ja löschen.

Warum auch einfach wenn "kompliziert" doch so viel schöner ist

Und aus dem Chaos sprach eine Stimme zu mir: "Lächle und sei froh, es könnte schlimmer kommen!", und ich lächelte und war froh, und es kam schlimmer...!

Man was hat die ISO-Erstellung gedauert ( über 1 Stunde)