druckerheini

Bingo - das war der entscheidende Hinweis. Danke Dir dafür. Tatsächlich unterstützt die Synology defaultmäßig auch 8+3-Namen, und das genannte Verzeichnis "0376_haxxxx" hat einen 8+3-Namen, der aus welchen Gründen auch immer mit "074" beginnt. Und der Sternchenoperator von "dir" lässt offensichtlich auch diese Verzeichnisse durch den Filter, selbst wenn man den Parameter /x nicht verwendet. Bislang dachte ich auch, die 8+3-Namen würden in den ersten 6 (Standard-) Zeichen mit dem normalen Datei-/Verzeichnisnamen übereinstimmen. Eine kurze Prüfung auf der Systempartition meines eigenen PCs ergab, dass das fast immer der Fall ist, aber auch hier gibt es vereinzelt Ausreißer, z. B. unterhalb von C:\Program Files: 06.12.2022 16:57 <DIR> WINDOW~1 Windows Defender 15.02.2023 07:55 <DIR> WIF4A9~1 Windows Defender Advanced Threat Protection 14.12.2022 13:33 <DIR> WINDOW~2 Windows Mail 08.09.2022 04:13 <DIR> WI54FB~1 Windows Media Player 07.12.2019 15:54 <DIR> WI7A8C~1 Windows Multimedia Platform 06.12.2022 15:54 <DIR> WINDOW~3 Windows NT 08.09.2022 04:13 <DIR> WI8A19~1 Windows Photo Viewer 07.12.2019 15:54 <DIR> WIBFE5~1 Windows Portable Devices 07.12.2019 10:31 <DIR> WINDOW~4 Windows Security (Als schnelle Lösung werde ich in dem Script an das "dir" nun noch ein "find" oder "findstr" anhängen, um die Existenz zu prüfen; irgendwann später stelle ich es dann auf PowerShell um.)

Hallo zusammen, hier habe ich ein ganz seltsames Phänomen, bei dem ich mich nicht erinnern kann, dass es mir schon einmal vorgekommen ist, weder zu seligen alten DOS-Zeiten noch mit einer der Windows-Versionen der letzten 30 Jahre: Ein DIR-Befehl zeigt manchmal falsche Verzeichnisse an! Aufgefallen ist mir das bei einem kleinen Script, das den Errorlevel eines DIR abfragt, um herauszufinden, ob es ein Verzeichnis schon gibt. Die Verzeichnisse liegen in einem übergeordneten Verzeichnis auf einer Netzwerkfreigabe eines älteren Synology-NAS und haben immer die selbe Struktur: Vierstellige Ziffernfolge, Unterstrich, beliebig lange Folge aus Buchstaben und Ziffern. Siehe Screenshot: Hier sieht man auch schon den Fehler: Ein DIR mit dem Muster "074*" findet auch das Verzeichnis, das mit "0376" beginnt! Doch es wird noch schräger: Benenne ich das Verzeichnis "0376_haxxxx" um, indem ich z. B. ein Zeichen ändere, anfüge oder lösche, dann wird das Verzeichnis von obigem DIR nicht mehr gefunden. Benenne ich es wieder zurück, ist der Fehler wieder da. Es scheint also mit dem konkreten Verzeichnisnamen zusammenzuhängen. Weitere Tests ergaben: Das Phänomen tritt auch von einem anderen PC aus auf und betrifft dieselben Verzeichnisse (1x Windows 10 Pro, 1x Windows 11 Pro, jeweils 22H2, 64 Bit, Patchstand Februar 2023). Dieses Verzeichnis "0376_haxxx" ist nicht das einzige, das falsch angezeigt wird. Es betrifft vielleicht 5% der ca. 1000 vorhandenen Verzeichnisse. Ein Muster konnte ich nicht erkennen. Kopiere ich die Verzeichnisse in ein anderes übergeordnetes Verzeichnis, tritt das Problem dort auch auf, und zwar mit exakt denselben Nummern. Zuerst hatte ich die Synology im Verdacht, dass dort im Dateisystem etwas nicht in Ordnung ist, obwohl sie nie irgendwelche Fehler gemeldet hat. Doch dann versuchte ich es per Powershell mit Get-ChildItem, und dort ist alles korrekt, von beiden PCs aus. Das lässt mich dann wieder an der Synology-Hypothese zweifeln. Hat jemand eine Idee, was hier vorgehen könnte oder was ich noch testen könnte? Danke

Das ist ein Selbstbau-PC. Das Board ist ein MSI MAG B660M Mortar DDR4 mit aktuellem BIOS 190, die CPU wie erwähnt eine Intel i5-12500. Ich habe es zwischenzeitlich noch an einem alten PC getestet, der hier noch herumsteht (i5-46xx, Gigabyte H87-UD3) - dasselbe Verhalten. Mit dem Notebook des Kollegen aus dem vorherigen Beitrag sind es also schon drei Kisten, die sich so verhalten Ist dieses Verhalten eventuell vom BIOS bzw. dessen Einstellungen abhängig? Da gibt es ja schon viele Energiespar-Einstellungen... Nachtrag: Das, was beim Einschalten kurz "losheult", ist der Netzteillüfter (be quiet System Power 9, 500 W). Nach ca. 4 Sekunden ist er dann völlig leise.

So kenne ich es auch, wobei im "hybriden Standbymodus" der Speicherinhalt ebenfalls auf die Festplatte geschrieben wird, für den Fall, dass der Strom ausfällt. Sowas habe ich befürchtet, wobei es immerhin auch denkbar wäre, dass im hybriden Standbymodus einfach nur der Strom abgeschaltet wird, da sich der Speicherinhalt ja schon auf der Platte befindet. Das wäre zu testen, immerhin steht der PC im Nachbarraum, durch eine geschlossene Tür getrennt. Im Betrieb ist der PC nahezu lautlos (Office-PC mit i5-12500, großer Kühlkörper, leise und langsam drehende Lüfter, gedämmtes Gehäuse), nur beim Einschalten drehen die Lüfter kurz hoch. Nach wenigen Sekunden hört man nichts mehr.

Moin, habe hier ein auf den ersten Blick merkwürdiges Phänomen: Wenn sowohl Standbymodus als auch Ruhezustand eingestellt sind, schaltet sich der PC beim Übergang vom Standby- in den Ruhezustand für ca. 10 Sekunden ein und dann gleich wieder aus. Ich habe das mal mit extrem kurzen Zeiten nachgestellt und kann es reproduzieren. Die Energieoptionen sind wie folgt eingestellt: Deaktivieren nach: 1 Minute Hybriden Standbymodus zulassen: Ein Ruhezustand nach: 2 Minuten Zeitgeber zur Aktivierung zulassen: Aktivieren Der Ablauf ist wie folgt: Minute 0: Der PC läuft Minute 1: Der PC geht in den Standby-Modus. Die Lüfter drehen sich nicht mehr, die Power-LED ist aus, er braucht ca. 2 Watt und lässt sich per Tastendruck wieder reaktivieren. Ereignisprotokoll: Kernel-Power, ID 42: "Das System wird in den Standbymodus versetzt. Ursache: System Idle" Minute 3: Der PC schaltet sich ganz kurz an. Die Lüfter heulen kurz auf (= Maximaldrehzahl), die Power-LED leuchtet, der Bildschirm bleibt jedoch dunkel. Ereignisprotokoll: Power-Troubleshooter, ID 1: "Das System wurde aus einem Standbymodus reaktiviert. [...] Reaktivierungsquelle: S4-Standbymodus in Ruhezustand" Minute 3 plus ca. 10 Sekunden: Der PC geht in den Ruhezustand. Die Lüfter drehen sich nicht mehr, die Power-LED ist aus, er braucht ca. 0,5 Watt und lässt sich per Tastendruck nicht wieder reaktivieren, nur über den Einschaltknopf. Ereignisprotokoll: Kernel-Power, ID 42: "Das System wird in den Standbymodus versetzt. Ursache: Hibernate from Sleep - Fixed Timeout" Ist dieses Verhalten normal? Kann man es abschalten (in Windows oder evtl. auch im BIOS), sodass der PC vom Standbymodus in den Ruhezustand wechselt, ohne dass er zwischendurch kurz laut wird? Oder ist das technisch bedingt und eine Beeinflussung daher nicht möglich? (Windows 10 Pro 22H2 incl. aller Updates bis Januar 2023.) Danke.

Volltreffer! Auch bei diesem PC war der Dienst deaktiviert, warum auch immer. Es genügt, ihn auf "Automatisch" oder "Manuell" zu stellen, der Druckerinstallationsassistent startet ihn automatisch und stellt ihn ggfs. auf "Automatisch" um. Danke für den Hinweis - Problem gelöst! (Doof, dass da keine Fehlermeldung erscheint, sondern sich der Assistent einfach beendet :-/)

Jetzt habe ich nochmals weitergetestet: rundll32 printui.dll PrintUIEntry /il sollte ebenfalls die GUI anzeigen, mit der man den neuen Drucker anlegen kann. Man sieht kurz ein Fenster aufpoppen, das sich sofort wieder schließt, zu schnell, um einen Screenshot anzufertigen., Es sieht genau so aus wie beinem Klick auf "Drucker hinzufügen" aus "Geräte und Drucker". Was jedoch funktioniert, ist den Drucker via rundll32 printui.dll PrintUIEntry /im anzulegen. Dann erscheint das Fenster "Drucker hinzufügen", über das ich Anschluss, Treiber und Druckername auswählen kann, damit funktioniert dann auch das Anlegen des Druckers. Nur eben nicht über "Drucker hinzufügen" aus "Geräte und Drucker", dies ruft offenbar den erstgenannten Befehl auf. Die seither erschienenen Windows-Updates von Dezember 2022 und Januar 2023 haben nichts geändert. Hat jemand eine Idee, wie man sowas als Nicht-Entwickler debuggen kann? printui.dll wird schon nicht defekt sein, das hätte sfc /scannow ja repariert (es handelt sich um die Version 10.0.19041.1806 vom 08.09.2022). Google fand auch nichts Passendes...

Keine Sicherheitssoftware außer dem Windows Defender. Alle Updates sind installiert (incl. November 2022). Keine Tuning-Software ist installiert, allerdings habe ich dem Windows ein wenig das Petzen abgewöhnt (Privacy-Einstellungen alle auf "größtmöglich" gestellt, DiagTrack-Dienst deaktiviert usw.), doch das mache ich bei jeder WIndows-10-Neuinstallation so und nie gab es hinterher Probleme mit dem Einrichten neuer Drucker. Ein sauberer Systemstart hat auch nichts verbessert. Es scheint übrigens ein reines GUI-Problem zu sein, über eines der Scripts in C:\Windows\System32\Printing_Admin_Scripts konnte ich den Drucker anlegen. Der Assistent funktioniert allerdings immer noch nicht...

Hallo zusammen, habe hier einen PC mit frisch installiertem Windows 10 Pro (22H2, Version 10.0.19045.2311) vor mir und möchte einen weiteren lokalen Drucker zusätzlich zu dem schon vorhandenen installieren. Schon ein paar 100x gemacht, doch auf dieser Kiste funktioniert der Druckerinstallationsassistent nicht. Es geht ganz kurz ein Fenster auf und sofort wieder zu, viel zu schnell, um irgendetwas darauf erkennen zu können und das war's dann. Reproduzierbar. Im Ereignisprotokoll ist nichts Auffälliges zu sehen. Die Standardmaßnahmen wie Neustart des Spoolerdienstes, Reboot, sfc /scannow haben alles nichts geholfen. Der schon installierte Drucker funktioniert problemlos, die Druckereinstellungen und -eigenschaften kann ich ändern, nur eben keine neuen Drucker hinzufügen. Kennt jemand das Phänomen und evtl. eine Lösung? Danke

Bingo - jetzt scheint das Phänomen verschwunden zu sein! Danke für den Tipp, ich werde noch eine Weile beobachten. Weißt Du auch, warum es nun weg ist und was die Microsoft-Updates damit zu tun haben?

Den hatte ich irgendwann letztes Jahr aktualisiert (Intel HD 4600), es war die Version 10.18.14.4578 vom 04.01.2017 drauf. Bei Intel fand ich eine Version 10.18.14.4889 vom 14.12.2017, habe diese installiert, aber ohne Verbesserung. Was ja wirklich auffällig ist, dass beim ersten Versuch, den PC per Tastendruck aufzuwecken, dieser nach 2 Sekunden wieder ausgeht. Es ist noch nicht einmal das Logo des AMI-BIOS zu sehen. Wie zum Teufel kann ein Windows-Update das Starten eines PCs in einer Phase beeinflussen, in der noch nicht einmal das BIOS initialisiert ist?

Oops - gibt es doch noch einen etwas neueren? Tatsächlich, eine Version 10.1.1.42. Habe sie gerade heruntergeladen und installiert, das Problem ist damit jedoch nicht behoben :-/

Siehe oben: Es ist das aktuelle BIOS (F10 vom 18.08.2015). Ein neueres gibt es nicht. Das Board ist ca. 4 Jahre alt. Und das Phänomen korreliert 100% mit den Microsoft-Updates ab Januar 2018.

Das BIOS ist aktuell (F10). Zum Chipsatztreiber: Die aktuelle Version sowohl bei Gigabyte als auch bei Intel trägt die Versionsnummer 9.4.0.1027 vom 18.10.2013, der Gerätemanager zeigt mir jedoch eine 10.1.1.38 vom 03.10.2016 an, also sogar neuer (wo immer der auch herkam, möglicherweise über ein Windows-Update?)

Hallo, wenn ich die kumulativen Updates meines Windows-8.1-PCs von Januar oder Febraur 2018 installiere, passieren merkwürdige Dinge, wenn ich meinen PC wie gewohnt in den Energiseparmodus schicke (entweder automatisch nach 30 Minuten wie in den Energieoptionen festgelegt oder manuell via "psshutdown.exe -d -t 0 -v 0"): Normalerweise kann ich den PC mit einem Tastendruck auf der Tastatur wieder aufwecken, in <5 Sekunden ist er wieder da. Mit einem der Updates passiert folgendes: Taste auf der Tastatur drücken - PC geht an und nach ca. 2 Sekunden wieder aus. Wieder eine Taste drücken: Nichts passiert (!) PC per Schalter einschalten: Der Bootvorgang beginnt, nach ca. 10 Sekunden schaltet sich der PC wieder aus. PC nochmals per Schalter einschalten: Der Bootvorgang beginnt von neuem und der PC fährt hoch. Dieses Verhalten ist reproduzierbar. Sobald ich das Update deinstalliere, ist mit dem Energiesparmodus alles wieder ok. Hat jemand eine Idee, was da vorgeht und wie ich die Updates installieren kann, ohne den Energiesparmodus kaputtzumachen? Mainboard: Gigabyte H87-HD3 CPU: Intel Core i5-4570 Danke für jeden Hinweis.

Hallo Günther, danke für die schnelle Antwort. In der Tat startet da ein neuer Prozess "DeviceDisplayObjectProvider.exe", das ist jedoch ein Microsoft-Prozess und nicht von einem der installierten Druckertreiber. Die CPU-Last dieses Prozesses ist dauerhaft 0%, ich habe ihn dennoch mal testweise abgeschossen, das Fenster "Geräte und Drucker" blieb bestehen, ebenso wie die CPU-Last von explorer.exe. TrustedInstaller.exe läuft nicht, weder mit noch ohne "Geräte und Drucker". Die VM hatte schon vorher 2 CPUs, nun hat sie testweise 6 bekommen, das hat das Problem nur ein wenig entschärft, seitdem ist der Server immerhin noch benutzbar und die gesamte CPU-Last 20-80% - vorher waren es eher 80-100%. An den Druckertreibern (alles Universaltreiber) hat sich längere Zeit nichts geändert...

Hallo zusammen, habe hier ein seltsames Phänomen auf einem Windows 2008 R2-Druckserver (aktueller Patchstand, virtualisiert unter VMware, 4 CPUs, viel RAM...), der ca. 2000 Drucker hostet. Die CPU-Last dieses Servers ist normalerweise sehr gering (meist <5%, nur ganz sporadische Spitzen, wenn jemand wirklich was Größeres druckt). Wenn jemand jedoch auf dem Server "Geräte und Drucker" aufruft, geht die CPU-Last des deutlich in die Höhe und springt ziemlich unruhig zwischen 20% und 80% hin und her, und zwar solange, bis das Fenster geschlossen wird., danach ist wieder Ruhe. Der Taskmanager zeigt den Prozess "explorer.exe" als Ursache dieser Last an. Der Start der "Druckverwaltung" hingegen erzeugt diese Last nicht. Google spuckte mir einige Treffer in Richtung "Drucker werden überhaupt nicht angezeigt" oder "Drucker suchen dauert ewig" aus, beides ist hier jedoch nicht der Fall: DIe Drucker werden immer angezeigt, und das nach ca. 20-30 Sekunden; dies wäre bei 2000 Druckern ja durchaus vertretbar, aber wenn 2-3 Benutzer "Geräte und Drucker" geöffnet haben, ist der Server so langsam, das sogar das Verbinden von Druckern lange dauert. Irgendwelche Ideen? Danke.

Hallo, kennt jemand eine Möglichkeit, die riesenlange Liste von Druckertreibern, die ein Windows 2008 R2-Server beim Anlegen eines neuen Druckers anbietet, zu entfernen, so dass nur noch die schon installierten (Fremd-) Druckertreiber zur Auswahl angeboten werden? Unter Windows 2003 konnte man das zuverlässig durch Löschen/Umbenennen der Datei c:\windows\inf\ntprint.inf hinkriegen, doch dies funktioniert unter Windows 2008 R2 nicht mehr. Danke.

Hallo zusammen, kennt jemand eine Möglichkeit, Druckeranschlüsse scriptbasiert zu löschen (also so, wie man es manuell via Drucker und Faxgeräte - Datei - Servereigenschaften - Anschlüsse - Anschluss auswählen - Löschen kann?) rundll32 printui.dll,PrintUIEntry gibt das offenbar nicht her, und wenn ich einen Anschluss direkt aus der Registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors\Standard TCP/IP Port\Ports\<Anschlussname> herauslösche, benötigt der Printserver einen Neustart, damit er aus der Liste verschwindet. Hat jemand eine Idee? Danke.

Das Verzeichnis liegt tief vergraben unter %ALLUSERSPROFILE%\Anwendungsdaten.

Genau so (abgesicherter Modus) habe ich die NTFS-Berechtigung ja für den Benutzer "Gast" vergeben, und damit funktioniert es ja auch. Das mit den identischen Benutzern (samt Passwörtern) werde ich nochmals prüfen. Was mich jedoch irritiert, ist, dass nicht einmal ein Verbindungsversuch mit dem angemeldeten Benutzer (egal, ob ich ihn beim "net use" mitgebe oder nicht) geschieht, der dann ggfs. fehlschlägt, sondern immer nur versucht wird, mit dem Benutzer "Gast" zuzugreifen. Ist das ein normales Verhalten bei XP Home? Klar wäre ein dedizierter Server (mit einem Windows 7 oder 8 Professional) sauberer, aber noch eine Maschine wollen sie sich nicht hinstellen, und die 6 Jahre alte XP Home-Kiste wird kommendes Jahr irgendwann abgelöst werden, dann hoffentlich durch ein Professional-Betriebssystem. Bis dorthin braucht es eben eine Lösung. Die jetzige ist selbstredend unschön - wenn es unter den gegebenen Randbedingungen (eben das ganze Home-Zeugs) eine bessere Lösung geht als über den geöffneten Gastzugang und die entsprechend gesetzten NTFS-Rechte im abgesicherten Modus, würde ich diese natürlich bevorzugen.

Yepp - dies habe ich explizit getestet gehabt.

Die Freigabe wird zusammen mit einem Datenbankdienst von einer Anwendung benötigt, beides läuft auf diesem PC. (Das Notebook ist nur der Client, der XP-Home-PC sowohl Client als auch Server. Es handelt sich um ein kleines Home-Office.) Ich dachte, genau dieses getan zu haben, werde ich jedoch nochmals explizit überprüfen, vielleicht auch mal mit einem neu angelegten Benutzer auf beiden Seiten. Doch warum versucht der Client dann immer nur einen Zugriff als "Gast" und nicht zunächst als der angemeldete Benutzer, zumindest laut Ereignisprotokoll?

Hallo, gestern bin ich an einem PC mit Windows XP Home fast verzweifelt. Die simple Anforderung: Es soll dort ein Verzeichnis freigegeben werden, das von anderen PCs (meist einem Windows 8-Notebook) verwendet werden kann. XP Home unterstützt ja zunächst nur die "einfache Dateifreigabe", also das Verzeichnis freigegeben und versucht, es per "net use" vom Notebook aus anzusprechen. Die Laufwerksverbindung wurde hergestellt, der Laufwerksbuchstabe war im Explorer sichtbar, doch jeder Versuch, auf das Laufwerk zuzugreifen, endete mit einem "Zugriff verweigert". Nun suchte ich mir einen Wolf, schaltete alles ab, was nur entfernt nach Firewall/Virenschutz roch, legte testweise Admin-Benutzer an, um mich über diesen zu verbinden, versuchte es von einem anderen WIndows XP Home-PC aus (dasselbe Verhalten, an Windows 8 liegt's also wohl nicht)... immer dasselbe: "net view \\hostname" zeigte die Freigabe brav an, "net use r: \\hostname\freigabename" stellte die Verbindung her, doch ein "dir r:" ergab "Zugriff verweigert". Irgendwann kam ich auf die Idee, ins Ereignisprotokoll zu schauen, und siehe da: Es wird immer versucht, als "Gast" zu verbinden (auch dann, wenn ich die Verbindung explizit mit einem anderen Benutzernamen aufbauen wollte!) Ist das unter XP Home immer so? Also testweise den Gastzugang aktiviert, doch immer noch keine Besserung. Liegt es etwa an den Rechten im Dateisystem? Den Reiter "Sicherheit" gibt es in der Home-Version ja nur im abgesicherten Modus (welche Drogen kursieren unter den Entwicklern in Redmond, um sich sowas einfallen zu lassen?), also den PC in diesem Modus neu gestartet, dem Benutzer "Gast" Vollzugriff auf das freigegebene Verzeichnis gegeben, und nun funktioniert der Zugriff auf die Freigabe! Doch kann das wirklich die sinnvollste Vorgesehensweise sein? Möglicherweise mache ich einen ganz einfachen Denkfehler, da ich selbst nur mit Pro-Versionen arbeite und die Home-Versionen nicht bis ins Detail kenne - wer setzt mich auf das richtige Gleis? Danke.

Das Problem tritt irgendwann mit jedem Benutzer (auch Administrator) auf. Berechtigungen sind natürlich vorhanden, sonst könnte ich das Verzeichnis nach Abschießen des Explorers nicht löschen. Avira habe ich testweise deinstalliert, doch das Problem kam bald wieder. Ich habe noch nicht geschafft, es gezielt zu provozieren, doch habe ich den Eindruck, dass es schneller erscheint, wenn ich ganze Verzeichnisbäume im Explorer hin- und herschiebe. Übrigens kann ich dann das Verzeichnis auch nicht umbenennen. Ich habe nun ganz mutig im Process Explorer der explorer.exe die entsprechenden File Handles unterm Hintern weggezogen, und das Resultat war wie von mir erwartet: Ich konnte das Verzeichnis daraufhin problemlos löschen. Mir würde also ein Tool reichen, das nicht nur auf Prozessebene arbeitet, sondern auch tiefer reinschaut, vielleicht kriege ich dadurch raus, welcher Teil des Explorers (ich vermute nach wie vor eine Shell Extension) das Problem verursacht.