Beiträge

Fehler beim Öffnen einer PDF-Datei per Doppleklick mit Adobe Reader X

Was es nicht alles gibt. Ein User meldet eine Fehlermeldung beim Öffnen eines PDFs.

„Before processing you must first launch Adobe Acrobat and accept the End User License Agreement.“

Andere PDFs lassen sie problemlos öffen. Auch dieses eine vermeintlich fehlerhafte Dokument läßt sich per Datei öffnen Dialog fehlerfrei öffnen. Nach kurzer Recherche (Gottseidank ist man mit solchen Problem selten allein) stellt sich ein kurioser Bug im Adobe Reader heraus. Wenn das PDF-Dokument die Buchstabenkombination CR im Dateinamen enthält, kommt es zu o.g. Fehler. Umbenennen hilft.

 

ODBC-Treiber unter Windows 7 64 Bit

Bei der Suche nach o.g. Problematik bin ich auf folgendes Blogposting gestoßen:Copy & Paste von http://www.hannes-bischof.de/?p=10

Gestern bin ich auf ein Problem mit ODBC-Treibern unter 64Bit Systemen wie z.B. Windows 2003 Server oder Windows Vista gestoßen. Dabei sollte eine .NET Anwendung die bisher auf allen 32Bit Systemen problemlos lief auf einem 64Bit Windows 2003 Server installiert und betrieben werden. Das Starten der Anwendung war auch problemlos möglich nur beim Verbinden mit der Datenbank konnte meine Anwendung den ODBC-Treiber bzw. den zugehörigen DSN nicht finden.
 
Nach aufwendiger Suche hat sich als erstes gezeigt das unter 64 Bit Systemen ODBC nicht gleich ODBC ist. Dies liegt daran das es zwei Arten von ODBC Treibern gibt, 32Bit und 64Bit ODBC Treiber. Viele Systeme liefern bisher aber noch ausschließlich die 32Bit Treiber aus und installieren diese auch. Wenn man nun unter dem Menüpunkt Systemsteuerung->Verwaltung->Datenquellen die Einträge für den System-DSN, User-DSN oder den zugehörigen ODBC Treiber sucht wird man nichts finden. Hier werden lediglich die DSN’s und Treiber angezeigt die 64Bit tauglich sind.
 
Um sich nun auch die 32Bit Treiber und DSN’s anzeigen zu lassen gibt es aber einen Trick. Mit dem Programm odbcad32.exe, das unter C:WindowsSysWOW64odbcad32.exe zu finden ist, wird vom Aussehen her genau die gleiche Datenquellenanzeige gestartet wie unter Systemsteuerung->Verwaltung->Datenquellen, jedoch dieses mal mit den 32Bit Treibern und DSN’s. Wie kann aber nun meine Anwendung festlegen das sie einen 32Bit oder 64Bit ODBC-Treiber verwenden will? Im Sourcecode ist das meines Wissens nach gar nicht möglich. Generell ist es so das 32Bit Anwendungen automatisch auf 32Bit ODBC-Treiber zugreifen und 64Bit Anwendungen auf die 64Bit ODBC-Treiber. 
 
Deshalb muss man seiner Anwendung sagen das Sie explizit als 32Bit Anwendung ausgeführt werden soll. Dazu muss man im VisualStudio in den Projekteinstellungen seiner Windows-Anwendung (.exe Datei) unter dem Reiter „Erstellen“ die Zielplattform von „Any CPU“ auf „x86“ umstellen. Dadurch wird die Anwendung explizit als 32Bit Anwendung gestartet und auch die zugehörigen ODBC-Treiber benutzt. Dies ist nur im Projekt der Startanwendung (.exe) nötig, nicht bei evt. eingebundenen DLLs. Die Angabe „x86“ ist hier gleichzusetzen mit 32Bit Anwendung und „x64“ mit 64Bit Systemen. Bei „Any CPU“ wird die Anwendung als 64Bit Anwendung gestartet falls es sich um ein 64Bit System handelt.

Sysinternals ’newsid‘ für Windows 7 bzw. Windows Server 2008 R2 …

…wird es nicht geben. Und eigentlich hätte man es wohl auch nie gebraucht. Zu dem Schluss kommt zumindest der Author des Tools, Mark Russinovich bereits im November 2009. Jetzt ists auch bei mir angekommen.

http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx

msvcp71.dll – Nachtrag

Das vor ein paar Tagen festgestellte Problem mit der fehlenden msvcp71.dll nach einem VMware Tools Upgrade im %windir%system32 betrifft auch andere Applikationen. Im aktuellen Fall funktionierte die LAN Capi von AVM nicht mehr. Ein Server baut über einen AVM Ken! Client eine ISDN Verbindung zu verschiedenen Banken auf. Beim Versuch den Client zu starten erscheint aber wenigstens der Hinweis, daß o.g. dll-Datei fehlt.
Erneut von anderer Stelle ins System32 Verzeichnis kopiert, Ken!-Client Dienst neu gestartet und schon läufts wieder.

Nach VMware Tools Update SQL Datenbank defekt?

Nach dem kürzlich durchgeführten Update der ESX Farm auf vSphere 4 ließ ich den Update Manager mal testweise bei einigen VMs die VMware Tools und die Hardware Version updaten. Nach kurzer Zeit klingelt das Telefon, das Intranet geht nicht mehr. Ein kurzer Blick auf den Server verrät mir, daß die SQL Datenbank (SQL 2000 Desktop Engine) nicht mehr läuft, der Dienst läßt sich nicht mehr starten.
Der Update Manager erzeugt einen Snapshot der VM vor dem Update. Ich schob die Schuld auf den Snapshot, schließlich soll man das ja nicht mit DB Servern machen, stellte den vorherigen Zustand wieder her und beließ es mal vorerst bei der alten Version der Tools und vHardware Version.
Heute ‘spielte’ ich mit einer Kopie meines Intranetservers und führte nebenbei ein Update der VMware Tools durch. Da ich keinen Snapshot erzeugte sollte das ja ohne Probleme so nebenher gehen. Sollte….
Nach dem Neustart ging wieder der SQL Dienst nicht. Es schien also etwas mit dem Tools Update zutun zu haben. Einige Google Recherchen später fand ich heraus, daß es mit der fehlenden Datei msvcp71.dll zusammenhängen sollte. Ich erinnerte mich schwach, einen Hinweis auf eine eben solche dll ignorierenderweise weggeklickt zu haben da ich sie in den Zusammenhang mit den neuen Performance Countern gebracht und temporär für unwichtig gehalten hatte.
Eine Suche nach der msvcp71.dll auf der HDD der VM förderte mehrere Treffer zu tage, alle in der gleichen Version. Ich schnappte mir eine beliebige und kopierte sie nach %windir%system32.
Schon ließ sich der SQL Dienst wieder starten.
Ohne Worte…