Skip to content

The procedure entry point could not be located in the dynamic link library MSVCP90.dll

The original error message was a bit more cryptic:
  The procedure entry point Xbad@ds2@std@@XBYP3error_type@regex_constants@32@@Y
  could not be located in the dynamic link library MSVCP90.dll
The web is full of errors like this and various solutions are proposed but it seems to be important which application generates this error. In this case it was avgnt.exe. And indeed, installing the Microsoft Visual C++ 2008 SP1 Redistributable Package made the error go away :-)

Error 1603: A fatal error occurred during installation

While trying to install vCenter Server, the installation of the included Microsoft SQL Server 2005 Express Edition failed. In the install logs, one can find something like this:
Error: Action "ReportChainingResults" threw an exception during execution.
One or more packages failed to install. Refer to logs for error details. : 1603
        Error Code: 0x80070643 (1603)
Windows Error Text: Fatal error during installation.
  Source File Name: sqlchaining\sqlchainingactions.cpp
Compiler Timestamp: Sat Oct 25 08:47:07 2008
     Function Name: sqls::ReportChainingResults::perform
Source Line Number: 3521
It turned out not to be a DCOM issue and Microsoft had KB 968749 in place: the solution would be to obtain the latest servicepack for MSSQL 2005 Server. But as the package was included with the VMware bundle, applying a service pack to a not-yet-installed version of MSSQL 2005 Server did not seem like a sound option. However, their workaround worked like a charm, I even tried the Fix it for me thingy: a small executable had to be downloaded and some Microsoft magic is applied to the system. After doing this, vCenter Server could be installed just fine.

Well, almost: the %systemdrive% was a bit low on space and the installation stopped when there was no more space. Windirstat revealed that %windir%\$hf_mig$ was pretty big, but should not be deleted. However, moving this directory to another drive should be OK. After doing that, a junction was created to satisfy the old pathname. With that in place, the installation continued and the system seems fine so far.

Peer certificate cannot be authenticated with known CA certificates

So, this bittorrent site switched to HTTP Secure. And in the name of HTTPS Everywhere I praise them for that. Yet my beloved rTorrent client seems to have a problem with that:
(15:17:33) Peer certificate cannot be authenticated with known CA certificates: 
    "https://torrents.thepiratebay.org/4224797/debian-slink-i386-binary.4224797.TPB.torrent"
Which is strange, my browsers don't have a problem with that. But cURL disagrees:
$ curl -I https://torrents.thepiratebay.org/
  curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
  error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Hm, what up with that? The browser shows "Equifax Secure Certificate Authority" and there are indeed Equifax certificates in /etc/ssl/certs. But apparently not the correct ones:
$ strace curl -I https://torrents.thepiratebay.org/ 2>&1 | grep etc/ssl
stat64("/etc/ssl/certs/2f2c2f7c.0", 0xbf8e2148) = -1 ENOENT (No such file or directory)
So, cURL is looking for a certificate with the hash of 2f2c2f7c. Of course, we cannot construct the correct certificate just with that hash. But we can search for it :-)

Looking around, we find something like this. OK, the hash matches. But where's the certificate from? Searching a bit more brings us to "GeoTrust Intermediate CA Certificates for Rapid SSL". Extracting the GeoTrust Rapid SSL Primary Intermediate CA Certificate we can see:
$ openssl x509 -hash -fingerprint -noout -in geotrust_ca_rapid_ssl.crt 
2f2c2f7c
SHA1 Fingerprint=C0:39:A3:26:9E:E4:B8:E8:2D:00:C5:3F:A7:97:B5:A1:9E:83:6F:47
The hash matches ;-) We'll now move it to our default certificate store and run c_rehash to generate the correct symlink:
$ sudo mv geotrust_ca_rapid_ssl.crt /etc/ssl/certs/
$ sudo c_rehash /etc/ssl/certs
[...]
geotrust_ca_rapid_ssl.crt => 2f2c2f7c.0
Now cURL works fine:
$ curl -I https://torrents.thepiratebay.org/
HTTP/1.1 200 OK
Content-Type: text/html
ETag: "1070355883"
Last-Modified: Tue, 10 Nov 2009 11:25:43 GMT
Expires: Thu, 08 Sep 2011 11:22:36 GMT
Cache-Control: max-age=172800
Server: lighttpd
Content-Length: 5
Date: Tue, 06 Sep 2011 23:12:32 GMT
X-Varnish: 1297278148 1293045530
Age: 42648
Via: 1.1 varnish
Connection: keep-alive
...and so does rTorrent :-)

However, the question remains how trustworthy this GeoTrust Rapid SSL Primary Intermediate CA Certificate really is. You may feel more comfortable to just add the site's certificate to the certificate store (and not the whole CA):
$ echo | openssl s_client -connect www.thepiratebay.org:443 2>/dev/null | \
   sed -n '/BEGIN/,/END/p'  > tpb.crt
$ sudo mv tpb.crt /etc/ssl/certs
$ sudo c_rehash /etc/ssl/certs