12
Zugriff auf DLL in Freigabe
Hallo,
ich bin gerade dabei einen neuen Fileserver auf Windows Server 2016 Standard für eine Anwendung aufzusetzen und stoße da auf ein Problem, komme dort nicht mehr weiter. Folgendes:
In einer Freigabe liegt eine Anwendung die von einem Nutzer "Test" ausgeführt werden soll. Der Nutzer "Test" kann die Anwendung lokal auf dem Server ohne Probleme ausführen, aber sobald er dies auf der Freigabe über das Netzwerk macht, findet er bestimmte Dateien nicht mehr, obwohl sie in der selben Freigabe liegen. Die Nutzerrechte stimmen aber:
Er kann auf der Freigabe lesen und ändern. NTFS-Berechtigungen sind ebenfalls richtig gesetzt.
Speziell findet die Anwendung eine Client-DLL für die Verbindung zu einem Firebird DB Server nicht. Diese soll nachgeladen werden. Die Anwendung ansich ist nichts bekanntes. Handelt sich um eine maßgeschneiderte Software, die per ODBC-Treiber auf mehrere Datenbanken zugreift.
Client-DLL liegt im selben Pfad wie die Anwendung. Auch die Umgebungsvariable "PATH" ist schon dahingehend angepasst und zeigt in den richtigen Ordner.
Meine Vermutung: Irgendein Sicherheitsmechanismus von Windows (ich tendiere zum Client, kann aber auch beim Server sein) verhindert hier das ein auf einer Freigabe ausgeführtes Programm auf weitere Dateien zugreifen darf. Habe jetzt schon auf dem Client Defender Virenschutz und Browser-/App-Steuerung deaktiviert. Funktioniert aber leider weiterhin nicht. In den Internetoptionen beim Client habe ich auch die IP des Servers zum Intranet hinzugefügt, ebenfalls kein Erfolg.
Jemand noch eine Idee was das sein könnte?
Gruß
ich bin gerade dabei einen neuen Fileserver auf Windows Server 2016 Standard für eine Anwendung aufzusetzen und stoße da auf ein Problem, komme dort nicht mehr weiter. Folgendes:
In einer Freigabe liegt eine Anwendung die von einem Nutzer "Test" ausgeführt werden soll. Der Nutzer "Test" kann die Anwendung lokal auf dem Server ohne Probleme ausführen, aber sobald er dies auf der Freigabe über das Netzwerk macht, findet er bestimmte Dateien nicht mehr, obwohl sie in der selben Freigabe liegen. Die Nutzerrechte stimmen aber:
Er kann auf der Freigabe lesen und ändern. NTFS-Berechtigungen sind ebenfalls richtig gesetzt.
Speziell findet die Anwendung eine Client-DLL für die Verbindung zu einem Firebird DB Server nicht. Diese soll nachgeladen werden. Die Anwendung ansich ist nichts bekanntes. Handelt sich um eine maßgeschneiderte Software, die per ODBC-Treiber auf mehrere Datenbanken zugreift.
Client-DLL liegt im selben Pfad wie die Anwendung. Auch die Umgebungsvariable "PATH" ist schon dahingehend angepasst und zeigt in den richtigen Ordner.
Meine Vermutung: Irgendein Sicherheitsmechanismus von Windows (ich tendiere zum Client, kann aber auch beim Server sein) verhindert hier das ein auf einer Freigabe ausgeführtes Programm auf weitere Dateien zugreifen darf. Habe jetzt schon auf dem Client Defender Virenschutz und Browser-/App-Steuerung deaktiviert. Funktioniert aber leider weiterhin nicht. In den Internetoptionen beim Client habe ich auch die IP des Servers zum Intranet hinzugefügt, ebenfalls kein Erfolg.
Jemand noch eine Idee was das sein könnte?
Gruß
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 642057
Url: https://administrator.de/forum/zugriff-auf-dll-in-freigabe-642057.html
Ausgedruckt am: 20.04.2025 um 11:04 Uhr
12 Kommentare
Neuester Kommentar
Speziell findet die Anwendung eine Client-DLL für die Verbindung zu einem Firebird DB Server nicht. Diese soll nachgeladen werden. Die Anwendung ansich ist nichts bekanntes. Handelt sich um eine maßgeschneiderte Software, die per ODBC-Treiber auf mehrere Datenbanken zugreift.
Client-DLL liegt im selben Pfad wie die Anwendung. Auch die Umgebungsvariable "PATH" ist schon dahingehend angepasst und zeigt in den richtigen Ordner.
Client-DLL liegt im selben Pfad wie die Anwendung. Auch die Umgebungsvariable "PATH" ist schon dahingehend angepasst und zeigt in den richtigen Ordner.
Also liegt der Fehler wohl in der ODBC Konfiguration.
Die passende 32/64 Bit Version ist installiert?
Passendes C++ Runtime installiert?
Verbindungstest ist erfolgreich?
Das ist auch komisch: Beim Verbindungstest sagt er das die Datei ebenfalls nicht vorhanden ist, obwohl ich genau in dem Dialog diese auswähle.
Ich habe dann versucht mit Regsvr32 die DLL zu registrieren, hier genau das gleiche: Man gibt genau den Pfad an und dann behauptet er das die Datei dort nicht vorhanden ist, obwohl ich dort per Auto-Vervollständigung genau dahin geführt habe. Wenn ich die Datei lokal ablege, genau das gleiche Phänomen.
Er scheint sich irgendwie an dieser DLL zu stören.... aber wieso?
Ich habe dann versucht mit Regsvr32 die DLL zu registrieren, hier genau das gleiche: Man gibt genau den Pfad an und dann behauptet er das die Datei dort nicht vorhanden ist, obwohl ich dort per Auto-Vervollständigung genau dahin geführt habe. Wenn ich die Datei lokal ablege, genau das gleiche Phänomen.
Er scheint sich irgendwie an dieser DLL zu stören.... aber wieso?
Moin,
greifst du auf dei Freigabe per UNC zu? Evtl ist das das Problem
Versuchs mal mit gemappten Laufwerk
lg,
Slainte
greifst du auf dei Freigabe per UNC zu? Evtl ist das das Problem
Versuchs mal mit gemappten Laufwerk
lg,
Slainte
Es ist absolut interessant. Meine Testreihe:
1x Lenovo ThinkCentre Windows 10 Pro 20H2 (Hersteller-Image) - funktioniert nicht
1x HP ProBook Windows 10 Pro 20H2 (Hersteller-Image) - funktioniert nicht
1x MSI Tiny Mini-PC Windows 10 Pro 20H2 (Image von der Microsoft-Website) - funktioniert
Irgendwas scheint an den Hersteller-Images anders zu sein. Ich weiß nicht was. Meine Vermutung gehen in Richtung: Scheinbar wurde da eine andere Version der fbclient.dll mitgeliefert.
Aber ich frage mich: Warum?
Firebird ist jetzt nicht soweit verbreitet, das die Hersteller unbedingt standardmäßig eine Client DLL mitausliefern müssten. Macht ja gar keinen Sinn...
1x Lenovo ThinkCentre Windows 10 Pro 20H2 (Hersteller-Image) - funktioniert nicht
1x HP ProBook Windows 10 Pro 20H2 (Hersteller-Image) - funktioniert nicht
1x MSI Tiny Mini-PC Windows 10 Pro 20H2 (Image von der Microsoft-Website) - funktioniert
Irgendwas scheint an den Hersteller-Images anders zu sein. Ich weiß nicht was. Meine Vermutung gehen in Richtung: Scheinbar wurde da eine andere Version der fbclient.dll mitgeliefert.
Aber ich frage mich: Warum?
Firebird ist jetzt nicht soweit verbreitet, das die Hersteller unbedingt standardmäßig eine Client DLL mitausliefern müssten. Macht ja gar keinen Sinn...
Ist der Pfad in den IE Einstellungen in den vertrauenswürdigen bzw. Intranet Zone eingetragen? Ich weiß, klingt komisch warum der IE damit was zu tun haben sollte, ist aber in vielen Fällen so das Windows teilweise Pfaden nur vollständig vertraut wenn diese dort auch explizit hinterlegt sind bzw. der UNC einer entsprechenden Zone zugeordnet ist.
Das hatte ich bereits getestet. Brachte aber auch nichts.
Auf dem Rechner mit dem original Microsoft-Windows-Image brauchte ich dort nichts eintragen und es hat dennoch funktioniert. Bisher konnte ich aber noch nicht herausfinden was an den Hersteller-Images anders ist.
Auf dem Rechner mit dem original Microsoft-Windows-Image brauchte ich dort nichts eintragen und es hat dennoch funktioniert. Bisher konnte ich aber noch nicht herausfinden was an den Hersteller-Images anders ist.
Dann starte Procmon und schau selbst nach was da schief läuft.
Ja, werde ich probieren.
Ich habe jetzt den Rechner mal der Freude wegen zurückgesetzt und clean neuinstalliert, um zu sehen ob es danach immer noch funktioniert. Tut es nicht. Es liegt also nicht an den Hersteller-Images.
Ich vermute das zufälligerweise mit irgendeinem Programm eine Bibliothek oder eine Funktion mitgekommen ist, die es ermöglicht das die DLL geladen werden kann. Dies über Jahre nur durch Zufall funktionierte. Absolut beschämend an der Stelle, das mir die Programmierer dieser Software da nicht helfen können.
Ich habe jetzt den Rechner mal der Freude wegen zurückgesetzt und clean neuinstalliert, um zu sehen ob es danach immer noch funktioniert. Tut es nicht. Es liegt also nicht an den Hersteller-Images.
Ich vermute das zufälligerweise mit irgendeinem Programm eine Bibliothek oder eine Funktion mitgekommen ist, die es ermöglicht das die DLL geladen werden kann. Dies über Jahre nur durch Zufall funktionierte. Absolut beschämend an der Stelle, das mir die Programmierer dieser Software da nicht helfen können.
Ihr lagt von Anfang an richtig. Ich hatte nur zu wenig vertrauen.
Der Procmon hat mir geholfen dem Problem auf die Spur zu kommen. Wenn die fbclient.dll im Programm nachgeladen wird, kam dort das Stichwort "MSVCR.dll" und das diese nicht gefunden wurde.
Es handelt sich dabei um Microsoft Visual C++ 2010, das hier fehlt und benötigt wird. Scheinbar wird dies nicht automatisch installiert, weder standardmäßig ausgeliefert noch per Update.
Damit läuft es.
Vielen Dank.
Der Procmon hat mir geholfen dem Problem auf die Spur zu kommen. Wenn die fbclient.dll im Programm nachgeladen wird, kam dort das Stichwort "MSVCR.dll" und das diese nicht gefunden wurde.
Es handelt sich dabei um Microsoft Visual C++ 2010, das hier fehlt und benötigt wird. Scheinbar wird dies nicht automatisch installiert, weder standardmäßig ausgeliefert noch per Update.
Damit läuft es.
Vielen Dank.
Scheinbar wird dies nicht automatisch installiert, weder standardmäßig ausgeliefert noch per Update.
Sollte man vielleicht auch mal dem Entwickler mitteilen das die das als "Abhängigkeit" künftig mit in die Installationsroutine aufnehmen. Sowas gehört eigentlich ins QM eines jeden Programmierers und sollte diesem beim Testen sofort auffallen 
.Es handelt sich dabei um Microsoft Visual C++ 2010, das hier fehlt und benötigt wird. Scheinbar wird dies nicht automatisch installiert, weder standardmäßig ausgeliefert noch per Update.
Nein, wird sie nicht. Das ist aber schon seit über zehn Jahren so dokumentiert.
Habe ich dann auch gefunden:
https://firebirdsql.org/rlsnotesh/install2-win-readfirst.html#install2-w ...
Aber erst mal auf sowas kommen... scheinbar war das aber aus irgendeinem Grund in all den Jahren, in denen die Anwendung vorher gelaufen ist, kein Problem. Dem Programmierern ist es auch erst heute aufgefallen und der Kollege der es vorher betreut hatte, wusste auch von nichts.
Deshalb konnte ich mir auch nicht erklären wo das Problem liegt und hatte gar nicht soweit gedacht, das da irgendein Visual C++ fehlen könnte.
Sachen gibts, die sollte es eigentlich nicht geben.
https://firebirdsql.org/rlsnotesh/install2-win-readfirst.html#install2-w ...
Aber erst mal auf sowas kommen... scheinbar war das aber aus irgendeinem Grund in all den Jahren, in denen die Anwendung vorher gelaufen ist, kein Problem. Dem Programmierern ist es auch erst heute aufgefallen und der Kollege der es vorher betreut hatte, wusste auch von nichts.
Deshalb konnte ich mir auch nicht erklären wo das Problem liegt und hatte gar nicht soweit gedacht, das da irgendein Visual C++ fehlen könnte.
Sachen gibts, die sollte es eigentlich nicht geben.
