TRegistry Unterschied zwischen Delphi 7 und 2009

[Shark99]

Zitat:

Zitat von Popov (Beitrag 1300513)

Eine kleine Bitte. Teste mal die drei Zeilen

Delphi-Quellcode:

  with TRegIniFile.Create('Software\Vendor\Productname') do try
    WriteString('', 'Test', 'Testwert');
  finally Free end;

Neues Projekt erstellt und in c:\RegTest\RegTest.dproj gespeichert.

Ergebnis: Exception, Key wird nicht erstellt.

Projekt dann über Speichern als in d:\RegTest\RegTest.dproj gespeichert.

Ergebnis: Key wurde erstellt.

Habe danach beide Regtest.exe verglichen. Gleiche Größe, aber nicht gleicher Inhalt:
http://i.imgur.com/2qvbfVA.png
http://i.imgur.com/PQLeUaa.png

c:\RegTest\Regtest.exe nach d:\RegTest\Regtest.exe kopiert, läuft, Key wird erstellt.

[Shark99]

Zitat:

Zitat von jaenicke (Beitrag 1300521)

Zitat:

Zitat von Popov (Beitrag 1300513)

Damals habe ich irgendwo in der Hilfe gelesen (das finde ich jetzt nicht mehr), dass es sehr wichtig ist, dass der Schlüssel wieder geschlossen wird, weil sonst... irgendwas nicht richtig funktionieren wird.

Ein weiteres OpenKey, weil das dann relativ zum bereits offenen Schlüssel läuft. Sprich OpenKey auf Software, dann OpenKey auf Software\Microsoft öffnet Software\Software\Microsoft, wenn der erste Key nicht vorher geschlossen wurde.

Closekey braucht man nur bei relativen Pfaden, nicht wenn man mit \ anfängt und absoluten Pfad angibt.

[Popov]

Ich kann mich noch erinnern, entweder war es Delphi 1 auf Delphi 3 oder Delphi 2 auf Delphi 3, aber plötzlich funktionierte die Hälfte meiner Programme nicht. Der Grund war schnell gefunden. Ich hab vorher die ganze Zeit irgendwo einen kleinen Fehler gemacht (eine Zeile war falsch). Sonderbarerdweise hat Delphi 1 (oder 2) den Fehler geschluckt, da aufgrund eines internen Fehlers mein Fehler nicht so eng gesehen wurde. Bei Delphi 3 hat man Fehler dann beseitigt, und ich musste alles korrigieren.

Sowas kann auch vorkommen.

[Popov]

Zitat:

Zitat von Shark99 (Beitrag 1300538)

Hab das Projekt auf Fat32 Partition umkopiert, Verzeichnis gelöscht, zurück auf NTFS, keine Änderungen.

Wenn du das schon machst. Wer ist der Besitzer der Projektdateien? Wer darf alles die NTUSER.DAT ändern. Wer hat Rechte über den Zweig, bzw. in einzelnen Schlüsseln.

Was passiert wenn du '\Software\Vendor\Productname' in '\Software\Vendor2\Productname' änderst?

[Dalai]

Langsam gehen mir die Ideen aus, denn das ist echt seltsam, und es hängt ja ganz offensichtlich vom Pfad ab, in dem die EXE liegt. Einen hab ich noch: Lokale Sicherheitsrichtlinie (secpol.msc) > Richtlinien für Softwareeinschränkung > Zusätzliche Regeln. Was stehen dort für Regeln bzw. weisen diese auf irgendwelche Pfade hin?

Zitat:

Habe danach beide Regtest.exe verglichen. Gleiche Größe, aber nicht gleicher Inhalt:

Logisch. Jeder Kompiliervorgang wird zu einer anderen EXE führen, egal mit welchem Delphi (oder gar Compiler).

@Popov: Also wenn er ein neues Projekt erstellt hat und mit den drei Zeilen von dir ebenfalls nur eine Exception bekommt, ist da ein bisschen mehr faul als nur ein kleiner Fehler im eigenen Code.

Zitat:

Zitat von Popov

Wer darf alles die NTUSER.DAT ändern.

Das spielt keine Rolle, denn die kann keiner ändern, solange sie vom System im Zugriff ist (aka jemand angemeldet ist). Noch nicht einmal lesend kann man sie öffnen.

Zitat:

Wer hat Rechte über den Zweig, bzw. in einzelnen Schlüsseln.

Das ist in der Tat eine gute Frage. Andererseits geht's ja mit Delphi 7...

MfG Dalai

[Shark99]

Besitzer ist Administrators (WORK\Administrators) (der auch eingelogt ist).

"Was passiert wenn du '\Software\Vendor\Productname' in '\Software\Vendor2\Productname' änderst?"

Es ändert sich natürlich nichts.

[Shark99]

Zitat:

Zitat von Dalai (Beitrag 1300548)

Langsam gehen mir die Ideen aus, denn das ist echt seltsam, und es hängt ja ganz offensichtlich vom Pfad ab, in dem die EXE liegt. Einen hab ich noch: Lokale Sicherheitsrichtlinie (secpol.msc) > Richtlinien für Softwareeinschränkung > Zusätzliche Regeln. Was stehen dort für Regeln bzw. weisen diese auf irgendwelche Pfade hin?

Leider nein, der Zusätzliche Regeln Subkey ist nicht mal vorhanden.

[Popov]

Sorry, du hast es vermutlich irgendwo erwähnt, aber mit welcher Windowsversion bist du unterwegs? Ich hab da etwas mit 7 x64 und 8.1 x64 gesehen. Ist das so?

Es gibt zwar allgemein das Konto "Administrator", aber das ist meiner Meinung nach versteckt. Unter XP konnte man da nur mit Tricks ran. Es war das Reserve-Adminkonto. Wie das unter 7 und 8 ist, weiß ich aber nicht. In der Regel gibt es da auch das Konto Besitzer und Ersteller.

[Shark99]

Es ist Windows 7 x64. Mit den versteckten Admin meinst du wahrscheinlich den User SYSTEM (der mit Root von Unix vergleichbar ist, Admin hat ja bei weitem nicht alle Rechte).

[Dalai]

Popov, jetzt bringst du aber einiges durcheinander.

Zitat:

Zitat von Popov (Beitrag 1300552)

Es gibt zwar allgemein das Konto "Administrator", aber das ist meiner Meinung nach versteckt.

Nein, es ist standardmäßig deaktiviert, aber ganz normal sichtbar, und nach dem Aktivieren auch nutzbar.

Zitat:

Unter XP konnte man da nur mit Tricks ran.

Stimmt nur teilweise. XP Professional hat ein ganz normales Adminstratorkonto, da ist nix versteckt und auch nix deaktiviert dran. Bei XP Home hingegen gibt's - auf einem deutschen System - zum einen den Besitzer und zum anderen einen tatsächlich versteckten Administrator, der ausschließlich im abgesicherten Modus verfügbar ist. So gesehen tatsächlich ein "Reserve-Admin".

Zitat:

Wie das unter 7 und 8 ist, weiß ich aber nicht.

Seit Vista ist das vordefinierte Administratorkonto deaktiviert, aber das ist trotzdem ein ganz normaler Nutzer (naja, bis auf ein paar Ausnahmen bzgl. der UAC).

Zitat:

In der Regel gibt es da auch das Konto Besitzer und Ersteller.

Den Nutzer Besitzer gibt es ausschließlich im XP Home, sonst nirgendwo. Klar, man kann einen gleichnamigen Nutzer anlegen, aber das ist etwas anderes. Der "Nutzer" Ersteller ist kein Konto sondern spielt für die NTFS-Berechtigungen eine Rolle, nennt sich aber eigentlich Ersteller-Besitzer. Irgendwo hab ich mal einen Artikel darüber gelesen, und ich glaube mich sogar zu erinnern, dass dieser Name eigentlich aus zwei Namen besteht. Aber lassen wir das, denn das ist mal wieder OT ;).

MfG Dalai

[Popov]

Nein, ich meine wirklich das Konto "Administrator". Unter XP existiert das, ist aber im Willkommenfenster nicht sichtbar. Um es aufzurufen muss man eine Anmeldeform wählen in der man den Benutzer selbst eingeben kann.

Unter Windows 7 sieht es ähnlich aus. Es ist ein verstecktes Konto. Deshalb wundert es mich. Eigentlich kann man kein Konto "Administrator" erstellen, weil es schon da ist. Man kann es aber in der Regel auch nicht so einfach auswählen. Bist du sicher, dass dein Konto "Administrator" ist? Oder hat es nur Administrator-Rechte?

[Popov]

Zitat:

Zitat von Dalai (Beitrag 1300554)

Nein, es ist standardmäßig deaktiviert, aber ganz normal sichtbar, und nach dem Aktivieren auch nutzbar.

Ich weiß nicht was du unter deaktiviert verstehst, aber bei mir ist es unsichtbar, d. h. es erscheint nicht im Willkommenbildschirm. Bin ich im Willkommenbildschirm (zumindest unter XP, unter 7 habe ich es noch nicht getestet) und klicke zweimal schnell hintereinander Strg+Alt+Entf (ich hab es schon lange nicht mehr gemacht, ich glaube aber so war es) erscheint dein Anmelde-Dialogfenster (so wie es in Firmen üblich ist). Man kann nun als Benutzernamen "Administrator" eingeben. Und schon kann man in das Konto rein.

Was du meinst ist das dauerhafte Anzeigen von "Administrator" im Willkommenbildschirm.

[Sir Rufo]

Ihr seht da mehr als ich - aber der TE ist nicht mit dem vordefiniertem Administrator Konto angemeldet (oder er hat sich zwei mal vertippt):

Zitat:

Zitat von Shark99 (Beitrag 1300549)

Besitzer ist Administrators (WORK\Administrators) (der auch eingelogt ist).

"Was passiert wenn du '\Software\Vendor\Productname' in '\Software\Vendor2\Productname' änderst?"

Es ändert sich natürlich nichts.

[Shark99]

http://i.imgur.com/M19mxP5.png

[Dalai]

@Popov: Nein, es ist schon so, wie ich sage. Dass das Adminkonto im Willkommensbildschirm nicht sichtbar ist, ist wieder eine andere Sache, die nicht mit dem übereinstimmen muss, ob ein Konto aktiviert ist oder nicht. Sobald unter Win7 der vordefinierte Administrator (und nur um den geht's) aktiviert wird, ist der im Anmeldedialog sichtbar. Lassen wir das, denn das ist OT, und unwichtig, denn Shark99 ist als Admin angemeldet, egal mit welchem.

Zitat:

Zitat von Sir Rufo (Beitrag 1300557)

Ihr seht da mehr als ich - aber der TE ist nicht mit dem vordefiniertem Administrator Konto angemeldet (oder er hat sich zwei mal vertippt):

Nein, Shark99 hat sich zwar vertippt, denn er hat sicher keine Gruppe angemeldet, aber Administrators ist eben die Besitzgruppe der Dateien auf einem englischen Windows.

MfG Dalai

[himitsu]

Zitat:

Zitat von Popov (Beitrag 1300513)

Delphi-Quellcode:

      Reg.CloseKey; //wird gerne vergessen

Delphi-Quellcode:

destructor TRegistry.Destroy;
begin
  CloseKey;
  inherited;
end;

Deswegen macht Delphi das für Diejenigen. :angle2:

[Dalai]

Tja, dann bleibt nur noch, genauer zu untersuchen, was die EXE macht bzw. wie das aus Sicht des OS aussieht, inwiefern sich die beiden EXEn unterschiedlich verhalten (bzw. dieselbe an unterschiedlichen Orten). Das kann man mit Process Monitor machen, wie bereits von jaenicke in Post #4 vorgeschlagen.

MfG Dalai

[Popov]

Ist es so, dass allgemein alle Programme die auf dem Laufwerk kompiliert wurden Probleme haben, oder ist es nur dieses Programm?

[p80286]

Zitat:

Zitat von Popov (Beitrag 1300619)

Ist es so, dass allgemein alle Programme die auf dem Laufwerk kompiliert wurden Probleme haben, oder ist es nur dieses Programm?

Wenn ich ihn richtig verstanden habe, tritt das Problem bei Echsen auf, die in einem/mehreren Verzeichnisse(n) gespeichert ist.

Gruß
K-H

[Shark99]

Zitat:

Zitat von Popov (Beitrag 1300619)

Ist es so, dass allgemein alle Programme die auf dem Laufwerk kompiliert wurden Probleme haben, oder ist es nur dieses Programm?

Wie schon mehrmals beschrieben, tritt es nur auf wenn ich in Verzeichnissen kompiliere die neu erstellt werden, in Verzeichnissen die älter als einen Monat sind gibt es die Probleme nicht. Das betrifft nur c:\. auf d:\ geht es immer.

[Popov]

Womit sich die Frage stellt was vor einem Monat passiert ist?

Gehen wir mal davon aus, dass der Fehler nicht im Code ist, denn sonst würde auch mein Dreizeiler nicht funktionieren, muss das Problem irgendwo anders liegen.

Hättest du Probleme eine Datei zu erstellen, wäre die Sache klar, das liegt an den Rechten des Kontos über den Ordner. Übrigens, man kann auch die Rechte von Administratoren reduzieren, nur das schöne ist, sie können sich, soweit man sich wiederum nicht das Recht Rechte zu ändern entzogen hat, die Rechte wieder geben. Also Administrator-Rechte alleine sagen nichts auf. Auf der anderen Seite hast du ein Bild gepostet und danach sollte alles ok sein.

Übrigens, fast ähnlich wie im Explorer, kann man auch Rechte in Regedit vergeben und entziehen. Es wäre somit interessant zu sehen was die einzelnen User für Rechte in Regedit haben.

Kommen wir von FAT32 Lw D: zu NTFS Lw C:. Erstellst du das Programm auf Lw D:, erstellst du es im Grunde unter dem Benutzer "Jeder". Kopierst du es (nicht verschieben) auf Lw C:, müssten im Grunde die Rechte des aktuellen Nutzers angenommen werden.

Kommen wir zu einer unwahrscheinlichen aber durchaus möglichen Möglichkeit. Ich beziehe mich hier auf die unterschiedlichen Dateien unter Lw D: und Lw C:. Theoretisch könnte ja sein, dass man keine Leserechte an einer Unit hat. Das Problem wäre in dem Fall nicht der Ordner in dem du etwas kompilierst, sondern der Zugriff auf einen anderen Ordner, z. B. in Programme. Die Möglichkeit hat aber einen Hacken: ich dem Fall dürftest du auch nicht korrekt auf Lx D: kompilieren.


Ich empfehle dir noch einen Test. Geh unter Systemsteuerung auf Benutzer. Erstelle zwei Konten. Das eine Shark99A mit Standardrechten. Dabei geht nichts kaputt, du kannst das Konto anschließend inkl. erstellte Dateien wieder löschen. Dann erstellst du noch ein zweites Konto, Shark99B, mit Administratorrechten. Geh dann auf "Einstellung der Benutzerkontensteuerung" und stelle alles runter (es wird nichts mehr geblockt).

Sollte das das Programm bereits mit Shark99A funktionieren, ist in deinem Standardkonto etwas mit den Rechten durcheinander. Sollte es bei Shark99B funktionieren, wird da etwas geblockt.

[p80286]

Zitat:

Zitat von Popov (Beitrag 1300635)

Kommen wir von FAT32 Lw D: zu NTFS Lw C:. Erstellst du das Programm auf Lw D:, erstellst du es im Grunde unter dem Benutzer "Jeder". Kopierst du es (nicht verschieben) auf Lw C:, müssten im Grunde die Rechte des aktuellen Nutzers angenommen werden.

Das ist nicht ganz korrekt! Bei der Kopie von einem FAT-Laufwerk werden wie auch sonst die (NTFS-)Rechte des Zielverzeichnisses eingetragen (Bei FAT->NTFS gilt das auch für's Verschieben!). Auch wenn die "Dateieigenschaften" jeder als Bestzer vorgaukeln, ist der aktuelle Benutzer Besitzer der kopierten Datei.

Gruß
K-H

[Shark99]

Habe einen neuen Admin-User erstellt und er hat genau das gleiche Problem. Habe dazu noch bemerkt dass es sich nicht nur um ein Registry Problem handelt, sondern Dateien können auch nur gelesen, aber nicht geschrieben werde. D.h. eine Exe die von einem Verzeichnis gestartet wird, bei dem der Parent nicht älter als 07.04.2015 ist hat nur Lesezugriff auf die gesamte Festplatte. Ich werde wohl um eine Neuinstallation von Windows drin drumherum kommen. Warte aber wohl noch auf Windows 10.

[Luckie]

Ich blicke nicht mehr durch. Könntet du mal bitte eine Zusammenfassung der bisherigen Erkenntnisse verfassen?

Aber wenn es um die Registry geht, spielen doch Verzeichnisrechte keine Rolle. :roll: Guck dir mal in der Registry an wer welche Rechte für den Schlüssel hat.

[Shark99]

Zusammenfassung aller Erkenntnisse:

- es handelt sich nicht um ein Delphi Problem, sondern ein Windows Problem und muss am 07.04.2015 bei mir passiert sein
- ich bin als Admin-user eingelogt, kann mit dem Explorer alle Programme starten, kopieren, Dateien löschen etc, auch in Systemverzeichnissen
- Anlegen eines zweiten Admin-Accounts hilft nicht
- das folgende Problem betrifft nur c:\, mit d:\ geht alles wunderbar (andere Partition auf gleicher SSD)

Problem: Wenn eine beliebige Executable (also auch notepad.exe) aus einem Verzeichnis ausgeführt wird dessen Parent-Verzeichnis nach dem 07.04.2015 erstellt wurde, hat diese App nur Leserechte und zwar sowohl für die Registry als auch beim Schreiben von Dateien.

Beispiel a: 1. c:\ordner1 wird erstellt 2. notepad.exe hin kopiert und gestartet 3. Datei -> Speichern als -> My Documents: Notepad meldet dass ich keine Zugriffsrechte zum Speichern habe. Rechtsklick auf notepad.exe und 'Run as administrator' bringt gleiches Ergebnis.

Beispiel b: alles wie im Beispiel a, aber Ordner nicht c:\ordner1 sondern c:\windows\ordner1 und es treten keinerlei Probleme auf, weil c:\windows VOR dem 07.04.2015 erstellt wurde.

Ich habe mittlerweile 10 Stunden gegoogelt und das Problem nicht noch einmal gefunden. Also bleibt wohl nur Neuinstallation. :roll:

[Popov]

Du hast einen zweiten Admin-Konto erstellt. Hast du das Ganze auch mit einem Standard-Konto getestet?

Hier gilt nicht Admin = mehr Rechte, also kann man sich das Standard-Konto sparen.

[Shark99]

Ja, hatte auch einen normalen User erstellt, dieser hatte aber das Problem auch.

[Popov]

Wenn du Lust hast, noch ein Test. Lade und installiere mal das Tool Attribute Changer. Damit kannst du nicht nur Attribute ändern, sondern auch die Datum-/Zeitangaben für Ordner/Dateien. Ändere das Datum eines der Ordner auf ein Tag vor dem 07.04.2015.

Achso, solltest du das Programm installieren, es fügt ein Eintrag in das Kontextmenü des Explorers.

[jaenicke]

Wie schon gesagt:
Das einzig sinnvolle um wirklich festzustellen wo der Unterschied liegt, ist den Process Monitor zu starten und nachzuschauen...

[Shark99]

Zitat:

Zitat von Popov (Beitrag 1300911)

Wenn du Lust hast, noch ein Test. Lade und installiere mal das Tool Attribute Changer. Damit kannst du nicht nur Attribute ändern, sondern auch die Datum-/Zeitangaben für Ordner/Dateien. Ändere das Datum eines der Ordner auf ein Tag vor dem 07.04.2015.

Achso, solltest du das Programm installieren, es fügt ein Eintrag in das Kontextmenü des Explorers.

Hab das Datum mit Total Commander auf 01.01.2014 geändert. Keine Änderung.

[Shark99]

Zitat:

Zitat von jaenicke (Beitrag 1300918)

Wie schon gesagt:
Das einzig sinnvolle um wirklich festzustellen wo der Unterschied liegt, ist den Process Monitor zu starten und nachzuschauen...

Delphi-Quellcode:

00:23:08,3852819   RegTest.exe   8972   RegCreateKey   HKCU\Software\VendorTest\ProductnameTest   ACCESS DENIED   Desired Access: All Access

Kompletter Log angehängt.

[Shark99]

Das ganze noch auf d:\ statt c:\

Delphi-Quellcode:

00:31:26,9658857   RegTest.exe   6752   RegCreateKey   HKCU\Software\VendorTest\ProductnameTest   SUCCESS   Desired Access: All Access, Disposition: REG_CREATED_NEW_KEY

Logfile angehängt.

[Popov]

Zitat:

Zitat von Shark99 (Beitrag 1300946)

Hab das Datum mit Total Commander auf 01.01.2014 geändert. Keine Änderung.

Ich glaube auch nicht, dass es daran liegt, das wäre zu verrückt. Auf der anderen Seite, Total Commander macht nicht das gleiche wie Attribute Changer. Es gibt insgesamt drei Zeitangaben, Total Commander ändert aber nur eines von. Nicht das Erstellungsdatum.

Edit:

Und was die Registry angeht, die Angabe "access denied" bestätigt nur das was wir schon die ganze Zeit vermutet haben. Der Zugriff wird verweigert, nur warum? Ich gehe natürlich davon aus, dass du alle Schlüssel im Registry-Pfad auf Berechtigungen überprüft hast (Schlüssel wählen, rechte Maustaste, im Kontextmenü auf Berechtigungen klicken). Es kann kein "access denied" geben ohne dass es da steht.

[himitsu]

Es gibt in HKEY_CURRENT_USER eine Berechtigung "EINGESCHRÄNKTER ZUGRIFF", welche keine Schreibrechte besitzt.

k.A. wie und warum ein Programm dort reinrutschen könnte.
aber Google meint https://social.msdn.microsoft.com/Fo...echte-windows7

Taskmanager > Prozesse > Menü: Ansicht > Spalten > Datenausführungsverhinderung und Virtualisierung

[jaenicke]

Im Log sieht man, dass der eine Prozess eine hohe Integritätseinstufung hat und der andere eine niedrige.
Mehr dazu findest du hier:
https://msdn.microsoft.com/en-us/library/bb625957.aspx

Ich kann das reproduzieren indem ich auf einem Testrechner die UAC ausschalte. Leider reicht es nicht diese danach wieder zu aktivieren. Das Verhalten ist danach trotzdem so. Solche und ähnliche Probleme hatte ich durch das Ausschalten der UAC schon mehrfach, auch bei Kunden (sowas macht man ja auch nicht).
Eine Lösung, solltest auch du die UAC deaktiviert haben, habe ich leider nicht (außer eine Neuinstallation).

Versuchen kannst du auf Kommandozeile:

Code:

icacls regtest.exe /setintegritylevel High
(mit Adminrechten)

[p80286]

Zitat:

Zitat von p80286 (Beitrag 1300466)

Zitat:

Zitat von Shark99 (Beitrag 1300460)

Trotzdem ist es extrem merkwürdig weil ich als Admin eingelogt bin und UAC komplett aus ist. 'Run as Administrator' ändert an der Sache nichts.

Nun ja!

Er hat!
:roll:

Zitat:

Aber wenn es um die Registry geht, spielen doch Verzeichnisrechte keine Rolle. :roll: Guck dir mal in der Registry an wer welche Rechte für den Schlüssel hat.

:shock: Das kann nicht sein!


Gruß
K-H

[jaenicke]

Zitat:

Zitat von p80286 (Beitrag 1300988)

Er hat!
:roll:

Das hatte ich überlesen. Tja, mit der Sicherheit so fahrlässig umzugehen sollte man sich eben gründlich überlegen. Das rächt sich eben nicht nur durch einen potentiellen Virenbefall.

[Shark99]

Zitat:

Zitat von himitsu (Beitrag 1300950)

Es gibt in HKEY_CURRENT_USER eine Berechtigung "EINGESCHRÄNKTER ZUGRIFF", welche keine Schreibrechte besitzt.

k.A. wie und warum ein Programm dort reinrutschen könnte.
aber Google meint https://social.msdn.microsoft.com/Fo...echte-windows7

Taskmanager > Prozesse > Menü: Ansicht > Spalten > Datenausführungsverhinderung und Virtualisierung

http://i.imgur.com/qhlaHxM.png

[Shark99]

Zitat:

Zitat von jaenicke (Beitrag 1300951)

Im Log sieht man, dass der eine Prozess eine hohe Integritätseinstufung hat und der andere eine niedrige.
Mehr dazu findest du hier:
https://msdn.microsoft.com/en-us/library/bb625957.aspx

Ich kann das reproduzieren indem ich auf einem Testrechner die UAC ausschalte. Leider reicht es nicht diese danach wieder zu aktivieren. Das Verhalten ist danach trotzdem so. Solche und ähnliche Probleme hatte ich durch das Ausschalten der UAC schon mehrfach, auch bei Kunden (sowas macht man ja auch nicht).
Eine Lösung, solltest auch du die UAC deaktiviert haben, habe ich leider nicht (außer eine Neuinstallation).

Versuchen kannst du auf Kommandozeile:

Code:

icacls regtest.exe /setintegritylevel High
(mit Adminrechten)

UAC wieder aktivieren hilft leider nicht (schon vor 2 Tagen versucht).

Aber icacls regtest.exe /setintegritylevel High hat geholfen! Damit kann RegTest.exe auch in c:\RegTest den Registry-Key anlegen!

[Shark99]

Zitat:

Zitat von jaenicke (Beitrag 1300992)

Zitat:

Zitat von p80286 (Beitrag 1300988)

Er hat!
:roll:

Das hatte ich überlesen. Tja, mit der Sicherheit so fahrlässig umzugehen sollte man sich eben gründlich überlegen. Das rächt sich eben nicht nur durch einen potentiellen Virenbefall.

Hab UAC schon vor 5 Jahren abgeschaltet weil es nicht viel mit Virenbefall zu tun hat. 99% aller Rootkits lachen über UAC und ignorieren es einfach.