Application.Printer Access-Bug?

[DF6GL]

Hallo und guten Tag zusammen,

nach einigen Monaten der Abstinenz hier im Forum melde ich mich wieder, und gleich mit einem möglichen mir unbekannten Access-VBA-Bug zu beginnen:

Die Auswahl eines bestimmten Druckers mit

Code [Auswählen] Erweitern

Application.Printer = Application.Printers(0)   ' verwenden des Druckernamens statt Index hat keinen Effekt ! 


läßt Access noch ein paar Sekunden sang und klanglos abstürzen.  Im Taskmanager ist danach keine Access-Instanz mehr aktiv.

Die *.laccdb wird nicht gelöscht.

Das Gleiche passiert auch bei Ausführung in Direktfenster.

Aufgefallen ist mir das bei Umstellung einer funktionierenden 32bit-DB auf 64bit.

Das Fehlverhalten tritt auch bei einer neu erstellten leeren 64bit-DB auf, jedoch nicht bei einer 32bit-DB.

Über die GUI-(Kombi-)Auswahl des Druckers in der Berichtsansicht funktioniert das Drucken einwandfrei.

Die üblichen Maßnahmen wie kompilieren/reparieren, decompile und Import in neue DB-Datei helfen nicht.

Ein Quercheck mit Office 2016 Prof. Plus 64bit funktioniert problemlos.

Equipment:

Fujitsu Celsius_W550Power  64 GB Ram SSD 2TB
Windows 11 
Office 2021 LTSC  64 bit  (bzw. 32 bit)

alles aktuelle Updates


Hat jemand dieses Phänomen schon mal beobachtet, bzw. kann jemand das erklären?


Danke!

[Bitsqueezer]

Hallo,

ich weiß gar nicht mehr, wann ich zuletzt Printer in Access verwendet habe...
Meistens verwende ich einfach den Standarddrucker, da insbesondere Access Reports zickig sind ohne Ende.

Aber generell würde ich nicht einfach sofort an Application.Printer zuweisen, sondern erst mal testen, was als Ergebnis zurückkommt.

In der Hilfe zu "Printers" steht dazu ja eine Schleife: https://learn.microsoft.com/de-de/office/vba/api/access.printers

Damit kann man sich die Devicenamen ausgeben lassen, und der Zugriff per String sollte mit dem richtigen Namen auch funktionieren.

64Bit Access habe ich leider keins zur Verfügung, daher kann ich das nicht testen und unter 32Bit hat es ja funktioniert, da bringt Dir das nichts.

Also meine Empfehlung: Per Schleife mal alle ausgeben und sehen was dabei herauskommt und außerdem bei Verwendung von Index 0 das erst zu einer Objektvariablen zuweisen und dann testen, was da drin steht, am besten mit dem Locals-Fenster.

Dann kann man vor der Zuweisung ein ungültiges Objekt mit if abfangen.

Gruß

Christian
 

[PhilS]

Hallo Franz!
Schön, dich mal wieder hier zu lesen.

Code [Auswählen] Erweitern

Application.Printer = Application.Printers(0) 

Was mir direkt auffällt: Ein Printer ist ein Objekt. Also gehört dort eigentlich ein Set hin:

Code [Auswählen] Erweitern

Set Application.Printer = Application.Printers(0)

[DF6GL]

Grüß Euch, Phil und Christian!


mhmm.. ich denke, Application.Printer selbst ist eine Eigenschaft, während .Printers()  eine Aufzählung ist. Ob damit .Printers zu "Objekten" in diesem Sinne zählt, weiß ich jetzt nicht.

Wenn das zuträfe sollte sich der Errorhandler melden und das Access nicht einfach ohne jegliche Meldung abschmieren.


In allen Beispielen, die ich gefunden habe, wird kein Set verwendet.

Hatte es ja auch mit set ....  versucht, ist aber das gleiche Verhalten und ändert nichts.

Zudem tritt der Fehler nur in A2021 64bit auf...., bzw. ich habe nur bis jetzt A2016 64bit getestet, und da funktioniert die Zuweisung.

Ich werde zusätzlich noch verschiedene andere PCs, Windows365 und evtl. eine VM mit Win10 und O2021 heranziehen, um das Verhalten zu vergleichen.

Das Mysteriöse ist, dass sich Access unanständig nur so sich selbst killt, das gehört sich einfach nicht.. 

@Christian:

Aber generell würde ich nicht einfach sofort an Application.Printer zuweisen, sondern erst mal testen, was als Ergebnis zurückkommt.

Tja, wenn Access das nur zuließe  ...

sobald  auch nur Application.Printer in einer Codezeile ausgeführt werden soll, sagt Access nicht mal Auf Wiedersehen...

PS:
(Nur Info)

Habe da noch etwas in der Ereignisanzeige gefunden:

Name der fehlerhaften Anwendung: MSACCESS.EXE, Version: 16.0.14332.20839, Zeitstempel: 0x67735a82
Name des fehlerhaften Moduls: ntdll.dll, Version: 10.0.22621.4541, Zeitstempel: 0xe7035eba
Ausnahmecode: 0xc0000005
Fehleroffset: 0x000000000001dbde
ID des fehlerhaften Prozesses: 0x0xBFC
Startzeit der fehlerhaften Anwendung: 0x0x1DB71C42FFCB872
Pfad der fehlerhaften Anwendung: C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE
Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\ntdll.dll
Berichtskennung: 6d6f771d-a905-49b7-93b3-81946c9add37
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

Gruß
Franz, DF6GL

[Bitsqueezer]

Hallo,

ja, nur ist es ja Application.Printers, aus dem Du erst mal das Objekt holst. Wenn also Application.Printer (ohne s) das Problem ist, probiere es doch erst mal mit dem Auslesen.

ntdll.dll ist eine wichtige Systemdatei von Windows.

Hier hat jemand auch Probleme beim Drucken mit ntdll.dll mit einer möglichen Lösung:
https://answers.microsoft.com/en-us/windows/forum/all/applications-crashing-because-of-ntdlldll/8f3cfaad-71f8-4fb7-922e-112ff73c5a43

Hier gibt es Informationen, wie man die Datei prüfen und reparieren kann:
https://www.drivereasy.com/knowledge/fix-ntdll-dll-crash-issue/

Gruß

Christian

[Josef P.]

Hallo!

ich denke, Application.Printer selbst ist eine Eigenschaft, während .Printers()  eine Aufzählung ist. Ob damit .Printers zu "Objekten" in diesem Sinne zählt, weiß ich jetzt nicht.

Im Application-Interface ist die Eigenschaft Printer so definiert:

Code [Auswählen] Erweitern

Property Printer As Printer
    Member of Access.ApplicationDamit enhält diese Eigenschaft eine Referenz zu einem Printer-Objekt.

Wenn ich einen Bericht auf einem speziellen Drucker ausdrucken will, verwende ich meist die Printer-Eigenschaft des Berichts. Das führt bei mir auch mit 64bit-Access zu keinem Fehler.

Gruß
Josef

[DF6GL]

Hallo zusammen,

@Josef:

Danke für die Definition. Wie anfänglich gesagt, ist die Situation mir beim Umstellen einer DB von 32 bit auf 64 bit aufgefallen, und das hat mich gewundert. Die Berichte über ihre Printer-Eigenschaft einstellen zu können, ist mir klar. Das war, bzw. ist aber nicht im "Scope" der Umstellung enthalten. Es wird wohl sein müssen, wenn das Application.Printer-Problem nicht gelöst werden kann 

@christian:

Wenn also Application.Printer (ohne s) das Problem ist, probiere es doch erst mal mit dem Auslesen.

Naja, ich habe ja alles versucht...

Egal wo und wann (Code, Direktfenster) ich mich auf Applicatin.Printer oder Application.Printers beziehe und sobald der Code ausgeführt werden soll, stürzt Access ab. Ich habe keine Chance, die Eigenschaften des Printers-Objekts (z. B. Devicename)   auszulesen oder anzuzeigen.
Allesfalls zeigt mir Intellisense die Eigenschaften/Methoden des Printers-Objekts noch an.


Die Links werde ich mir und auch das Verhalten auf einem anderen Windows11-Rechner mit A2021 64bit noch ansehen.

Ich vermute jetzt auch, dass die Windows-Systemdatei einen Schuss hat...



Grüße
Franz, DF6GL

[knobbi38]

Hallo Franz,

der Fehlercode besagt:
"Der Fehlercode 0xc0000005 Verletzung bedeutet, dass ein Programm versucht hat, auf einen Speicherbereich zuzugreifen, der nicht für es reserviert ist."

Das würde auch den rigorosen Absturz erklären. Da müßte eigentlich auch etwas im Eventlog zu finden sein. Möglicherweise ist da tatsächlich ein BUG in der 64Bit-Version bei Zugriff auf diese Eigenschaft.

Gruß
Knobbi38
 

[DF6GL]

Hallo zusammen,


@Knobbi38:

einen Auszug aus der Eventliste habe ich vorher ja schon gepostet.. Dort steht, dass die Datei ntdll.dll ein Problem verursacht.

Und das ist auch der Knackpunkt.  Ich habe die ntdll.dll-Datei (mit gleicher Version natürlich) von einem anderen Windows11-Rechner kopiert und in den System32-Ordner gelegt, nachdem die originale Datei (in ntdll.dll_ ) umbenannt wurde. Nach einem Neustart tut Access jetzt so, als hätte es da nie ein Problem mit Application.Printer(s) gegeben.

Wenn jetzt  Windows11 an der Misere schuld war, dann entschuldige ich mich außerordentlich bei MS Access und hoffe trotzdem auf weitere gute Zusammenarbeit          .


Es fragt sich allerdings nur noch, woran die ntdll.dll erkrankt war und wodurch 

Aber diese Nachforschungen lass ich jetzt bleiben. 


Ich danke allen für die rege Diskussion.

[Bitsqueezer]

Hallo,

nicht unwahrscheinlich ist, daß Du Dir einen Virus eingefangen hast, weil gerade solche Systemdateien natürlich sehr beliebt sind. Ich würde das System einer intensiven Untersuchung unterziehen, angefangen mit "sfc /scannow" im CMD-Administrator-Terminal.
Hier eine Beschreibung dazu und anderen Maßnahmen:
https://www.deskmodder.de/wiki/index.php?title=Windows_11_reparieren_mit_DISM,_sfc_und_anderen_M%C3%B6glichkeiten

Es ist jedenfalls unüblich, daß man bei "normalem" Windows-Betrieb ein Problem mit der Datei ntdll.dll bekommt. Eingeschlossen die Möglichkeit, die Datei überhaupt austauschen zu können, was auf "herkömmlichem" Explorer-Weg etc. auch nicht direkt funktionieren sollte. Wenn Du das relativ problemlos austauschen konntest, würde ich hellhörig werden und davon ausgehen, daß sie alsbald wieder "anderweitig" ausgetauscht wird.

Also: Meine Empfehlung ist, dringend das System intensiv zu checken.

Gruß

Christian

[knobbi38]

Hallo Franz,

ich kann nur dringend unterstreichen, was Christian da noch angeführt hat. Es gibt da z.B. einen Virus "Virus:Win32/Floxif" welcher genau zu so einem Fehlerbild führt. Überlege mal, ob und was du zuletzt heruntergeladen hast. Möglicherweise hast du dir da etwas eingefangen.

Übrigens:
in einer Beschreibung zum Virus hieß es:

... because the virus will infect executable files on all your drives

Ich würde also auf jeden Fall mal einen Deep Scan mit einer Virusscanner machen, am besten Offline.

Wenn du noch keinen hast, vielleicht ist das ja etwa für dich dabei:
https://www.heise.de/download/product/desinfect-71642
https://www.heise.de/download/product/bitdefender-rescue-cd-56298

Grüße Knobbi38

[PhilS]

Wenn ein Manipulationsverdacht für eine ganz konkrete Datei (hier ntdll.dll) besteht, dann ist der erste, einfachste Check die Signatur der Datei zu überprüfen. Im Explorer die Datei markieren, Kontemenü: "Eigenschaften" -> "Digitale Signaturen" - "Details".

[DF6GL]

Hallo,


danke nochmal für die Hinweise, alle angesprochenen Maßnahmen habe ich selbstverständlich angewandt.

Es waren/sind keine Viren oder Ähnliches (mit unterschiedlichen Virenscannern) gefunden worden.

Sfc und Dism habe ich mehr als einmal laufen lassen, selbst Neu-Installation von Win 11 (eigene Daten beibehalten) und/oder Neuinstallationen von Office  haben das Problem nicht gelöst.

Weiterhin habe ich "verdächtige" Programme deinstalliert und auch alle Scheduler-Einträge deaktiviert um auszuschließen, dass sich darunter der Übertäter verbirgt.
 
Selbst die Signatur der alten und neuen Datei war identisch. Letztendlich ist es für mich auch ein kleines Mysterium        , aber der pure Austausch der Datei hat zum Erfolgt geführt, warum auch immer.


Um einen Hardware-Defekt auszuschließen, habe ich die OS-SSD in einen anderen Rechner eingebaut, mit demselben Ergebnis. Genauso als VHDX-Datei in einem HyperV-VM-PC



Der Rechner läuft bis heute ununterbrochen (von Update-Booten abgesehen) und ohne Absturz durch. 
Wenn es denn so bleibt, bin ich zufrieden....