none
Seit Windows 10 1903 funktion "altes" Programm mit eingebautem Visual Basic nicht mehr RRS feed

  • Frage

  • Ich habe hier ein Programm bei dem man Anpassungen über VBA vornehmen kann. Dazu startet man aus dem Programm heraus "Microsoft Visual Basic 6.5". Info liefert dazu: VBA Retail 6.5.1055 Version 1055, Forms3: 15.0.4737.100

    Bestimmte Funktionen vom Programm (z.B. Export nach Excel) sind wohl auch durch kleine VBA-Programme auf diesen Weg realisiert.

    Mit Windows 10 1809 (32bit und 64bit) kein Problem

    Bei Windows 10 1903 (32bit und 64bit) funktoniert das nicht.

    Da das Programm schon lange aus dem Support raus ist, wird es keine Fehlerbehebung durch den Softwarehersteller geben, die haben das Problem aber bestätigt.

    Alles was mir so eingefallen ist habe ich ausprobiert. Klappt nicht.

    Weiß jemand was Microsoft da geändert hat das dies nicht mehr funktioniert?

    Anmerkung: 16bit Code usw. ist das nicht, hätte sonst ja schon nicht mit den Vorgängerversionen Windows 10 64bit funktionieren dürfen.
    Freitag, 9. August 2019 11:13

Alle Antworten

  • Den kompatibilitätsmodus hast du wohl auch probiert?

    Da bleibt dir wohl nur, auf eine VM auszuweichen.

    Freitag, 9. August 2019 12:06
  • Yepp, schon ausprobiert.

    Was ich alles ausprobiert habe:

    Aufgefallen ist das nach einer Migration von Windows 7 Pro 32bit auf Windows 10 Pro 1903 32bit. Also in einer VM Windows 10 1903 64bit neu installiert, Anwendung installiert und funktioniert ebenfalls nicht. Selbes Spiel mit Windows 10 1803 64bit, Anwendung kann eingebaute VBA-Funktionen nutzen.

    SMB1 über Windows Features aktiviert. Die VBA-Quellcodefiles liegen nämlich auf einer Freigabe unter Windows Server 2003. Zugriff auf die Freigabe besteht.

    Windows Defender (oder wie der jetzt auch benannt wurde?) soweit es geht deaktiviert. In den Einstellungen des Windows Internet Explorers alles aktiviert/deaktiviert was ich gedachte habe das Einfluss haben könnte.

    Jetzt fällt mir nämlich ein das die Anwendung den Internet Exlporer als Host zur Anzeige nutzt.

    Keine Sandbox in den Features aktiviert.

    Windows Defender: Echtzeitschutz Aus, Cloudbasierter Schutz Aus, Automatische Übermittlung von Beispielen Aus, Manipulationsschutz Aus, Überwachter Ordnerzugriff: Benötigt den Echtzeitschutz, also auch aus.

    Ich habe auf jeden Fall jetzt sichergestellt das die Einstellungen wie oben sind, eventuell aktiviert sich der Defender ja von selbst wieder. Bei dem migrierten Rechner war Kaspersky Endpoint Security aktiv.

    Diverse Kompatibilitätsmodi probiert (Windows XP SP3, Windows 7) und Anwendung auch als Administrator gestartet. Einstellungen für Benutzerkontoeinstellungen durchprobiert.

    Dem Verzeichnis der Anwendung wo die *.vb landen volle Rechte gegeben. "jeder" darf alles. Vererbung ausgeschaltet.

    C:\Users\<USERNAME>\AppData\Local\VirtualStore ist leer.

    Mal sehen ob es weitere "Leidengenossen" gibt bei denen sich im Bereich *.vb und Windows 10 1903 etwas getan hat. Deshalb auch dieser Beitrag.

    Die IDE der Anwendung zur Anzeige und Erstellung von .vb kann ich öffnen, es landen aber keine .vb in den Ordner wo sie hingehören.

    Gerade mal geguckt, ob ich überhaupt eines meiner alten VB-Programme (als EXE) starten kann. Ja, ging. Ist also nicht so das generell VB6-Programme VB6 geblockt werden.


    Freitag, 9. August 2019 12:29
  • Kannst du die VB Scripte auf einer lokalen Quelle ablegen und darauf verweisen? Nur um auszuschließen, dass es ein Problem beim ausführen von Scripten aus Netzwerkquellen ist oder ein Netzwerkproblem?
    Freitag, 9. August 2019 13:13
  • Ich will an dieser Anwendung nichts an der Konfiguration ändern, bis die Migration durch ist muss die noch ein paar Wochen/Monate laufen.

    Mit viel Ehrgeiz könnte ich die sicherlich in eine VM in einem Testnetzwerk verfrachten und dann mit einem Client probieren, soviel Ehrgeiz habe ich jetzt aber auch nicht. :-)

    Bei den Tests durch den Hersteller meine ich herausgehört zu haben das die vb-quellcodes vom Serververzeichnis in ein lokales Verzeichnis C:\Anwendung kopiert werden und das passierte nicht. Dann wurden lökal die .vb abgelegt. Sah aber nicht so aus, als würden die dann ausgeführt werden.

    SMB1 habe ich definitiv aktiviert.

    Hatte gehofft (und hoffe immer noch) das jemand weiß was sich da zwischen den beiden Versionen geändert hat. Nicht einmal weil ich die Anwendung unbedingt zum Laufen bekommen muss, sondern aus Neugierde.

    Freitag, 9. August 2019 13:30
  • Das Hauptproblem dieser Anwendungen ist meistens, dass sie nicht alles an DLL's mitbringen was sie zur Lauffähigkeit benötigen.
    Windows hat bis Win8 die 32-Bit-VB6-Komponenten mit installiert. Dzu gehören diverse DLL's und Controls OCX.
    Seit Win10/Server2016 sind diese nun endgültig nicht mehr Bestandteil des Betreibssystems.
    D.h., Anwendungen, die ihre VB-Runtime nicht mitbringen stehen nun auf dem Schlauch.

    Um nun zu prüfen, was fehlt, kann man z.B. den Sysinternals Prozessexplorer laden und sich die geladenen DLL's der Anwendung ansehen. Diese sind mit dem Zielsystem dann abzugleichen.

    Nun ist es leider nicht damit getan, die fehlenden DLL's einfach ins Zielsystem zu kopieren, man benötigt dazu meist einen trusted Installer um die dll's in System32/SysWOW64 zu installieren und bei COM-Objekten ebanso auch zu registrieren.

    Ein weiterer Punkt ist die Netzwerkeinstellung von Ordnern, die ausführbaren Code enthalten.
    Hier arbeitet man wirklich vergebens, da Microsoft gerade diesbezüglich massive Sicherheitslücken geschlossen hat und teilweise die Ausführung insbesonders bei SMB1 blockiert.
    Diesbezüglich kann man nur bei den Internetoptionen die Server/Adressen als vertrauenswürdig hinterlegen.
    Dies hat i.Ü. nichts mit SMB1 zu tun. Mit SMB1 wird nur der Zugriff generell auf Netzwerke ermöglicht, die kein SBM2/3 unterstützen.
    Für die Ausführungsprobleme hat das keine Auswirkung.

    Kannst du denn die benötigten Daten vom Server nicht lokal kopieren und den Zugriff darauf umrouten/konfigurieren?
    Falls unbedingt ein Laufwerksbuchstabe benötigt wird, kannst du auch ein lokales Verzeichnis mittels "subst x: <Pfad>" auf das Laufwerk setzen.

    Freitag, 9. August 2019 15:23