2008 VW Touareg Tire Pressure Discrepancy

I drive a 2008 VW Touareg with stock 17″ Pirelli P255/60R17 Scorpion STR tires.
I noticed the VW recommended tire pressure was 2PSI higher than the tire’s maximum pressure rating.
The tire pressure sticker on the driver door indicated 46PSI, while the tire wall indicated a maximum tire pressure of 44PSI.
Overinflating tires is potentially very dangerous.
I posted my findings on the Club Touareg Forum, and other owners of similar vehicles confirmed the same information on their tire labels.
I opened a support case with VW USA asking what the correct recommended tire pressure is.
VW’s said that the label is correct.
I explained that the recommended pressure exceeds the maximum pressure, they said they would get back to me.
After a few weeks I was contacted and told that I should use the recommended pressure as indicated on the tires.
I explained that there is no recommended pressure indicated on the tires, just a maximum pressure, they said they would get back to me.
After about a month I was contacted and told to inflate the tires to less than the maximum rating.
Not much help.
 Since I made no real progress with VW support, I contacted Pirelli, and they were much more helpful.
I received this reply via email:
Thank you for your recent inquiry.
Pirelli recommends VW to advise owners of the Touareg VIN’s equipped with Pirelli P255/60 R17 106H TL RB (VO) Scorpion STR engraved with the marking MAX PRESSURE 300 KPa (44 PSI) that the tire is capable to be inflated at the maximum cold inflation pressure of 350 KPa (51 PSI) and that both tire markings
MAX LOAD 950 KG (2094 LBS) MAX LOAD 950 KG (2094 LBS)
MAX PRESSURE 300 KPa (44 PSI) MAX PRESSURE 350 KPa (51 PSI)
conform to FMVSS 139 and ETRTO requirements.
Pirelli Tire North America
Consumer Affairs
The table that references 950Kg for both 44PSI and for 51PSI still had me confused, so I called Pirelli directly.
The person informed me that this is a known issue of the tires being mislabeled, and that VW should know about it. 
I was told that the correct maximum pressure of the tires are 51PSI, and that I should follow the recommended rating on the VW door sticker of 39PSI front and 46PSI rear.
This is the label on the driver side door body pillar, rear tire pressure is 46PSI:
 
Click for large image.
This is the label is on the side of the door, underneath the latch, note the discrepancy with the other label, rear tire pressure is 44PSI:
 
Click for large image.
The tire markings indicate the maximum pressure is 44 psi:

Click for large image.

Click for large image.

Archived Content and Templates

I have now moved all old archived content from my website to this blog, the old pages contain links to the equivalent blog postings. I know the copy-and-paste blog formatting is not very elegant, but it will do.

I was using the standard Blogger “Tic-Tac” template, but the readable area was not wide enough to fit many of the images I embed in articles, and this would either skew the text, or cut of the images.
I found an article with step-by-step instructions on how to widen the “Rounders” template, and I am now using a widened “Rounders 4” template.
I don’t know why all the templates are fixed width, why not dynamically adjust the width based on the available space?
If you know of any wide or dynamic width templates, please let me know.

Broken Symbol Proxy

This post is about Microsoft Debugging Tools for Windows, symbol servers, and symbol proxy servers.
You can read my posts about this problem on the Microsoft WinDbg group, and on the Google Chromium group.
We run several symbol servers, and a single symbol proxy server that provides transparent access to all our symbols servers, as well as the Microsoft symbol servers.
I was debugging a Google Chrome crash, and was looking for symbols for Chrome. I was pleasantly surprised to find out that both Mozilla and Google have public debug symbol servers for Firefox and for Chrome. I added the Mozilla and Google symbol servers to our symbol proxy server list.
The problem was that the symbols for Firefox or Chrome did not download as expected, but when pointing directly to the Firefox or Chrome symbol servers the symbols would download correctly.
This worked:
symchk.exe “chrome.exe” /v /s “srv*c:\symbols*http://build.chromium.org/buildbot/symsrv”
This failed:
symchk.exe “chrome.exe” /v /s “srv*c:\symbols*http://our.symbol.server/symbols”
I captured network stack traces of the direct request and the proxy server request.
Direct request:
HTTP – Hyper Text Transfer Protocol
HTTP Command: GET
URI: /buildbot/symsrv/chrome_exe.pdb/A931F873616F40A4972373FAD37D562D1/chrome_exe.pdb
HTTP Version: HTTP/1.1
Accept-Encoding: gzip
User-Agent: Microsoft-Symbol-Server/6.11.0001.402
Host: build.chromium.org
Connection: Keep-Alive
Cache-Control: no-cache
Proxy server request:
HTTP – Hyper Text Transfer Protocol
HTTP Command: GET
URI: /buildbot/symsrv/chrome_exe.pdb/a931f873616f40a4972373fad37d562d1/chrome_exe.pdb
HTTP Version: HTTP/1.1
User-Agent: Microsoft-Symbol-Server/6.11.0001.402
Host: build.chromium.org
Connection: Keep-Alive
Cache-Control: no-cache
Pragma: no-cache
The problem turns out to be that the symbol proxy uses an all lowercase URI to access the symbol servers. This works with the Microsoft symbol server because they run IIS, and IIS is case insensitive. But, Mozilla and Google run case sensitive Linux based web servers, and when the symbol proxy changes the case of the request, the symbols are not found
We were running symproxy.dll version 6.8.4.0, and the latest release was 6.11.1.404. I upgraded the binaries to the latest version, hoping the problem would go away, instead the problem got worse. Now we were also unable to download symbols from the Microsoft’s own symbol server.
Reading the MSDN documentation for SymSetOptions(), I noticed two options that could affect the observed behavior; SYMOPT_CASE_INSENSITIVE, and SYMOPT_FAVOR_COMPRESSED.
I wanted to modify the symbol options while the symbol proxy was running, so I created an ISAPI filter DLL that will run in the same process space as the symbol proxy, allowing me to modify the symbol options. IIS calls GetFilterVersion() to initialize the filter, during this call I called SymSetOptions() and set SYMOPT_CASE_INSENSITIVE and SYMOPT_FAVOR_COMPRESSED.
Calling SymSetOptions() had no effect, and I quickly realized that I am on the wrong track.
SymSetOptions() is implemented by dbghelp.dll, while symproxy.dll does not load dbghelp.dll.
A bit of investigation revealed that symproxy.dll loads symsrv.dll using LoadLibrary(), and uses only two exports; SymbolServerSetOptions() and SymbolServerByIndex().
I found documentation for SymbolServerSetOptions(), but nothing for SymbolServerByIndex(). But dbghelp.h did include the function prototypes for both functions.
I changed my strategy, and decided to write a shim to sit between IIS and symproxy.dll, and another shim to sit between symproxy.dll and symsrv.dll. This approach would allow me to see all the values passing between the DLLs.
I modified my ISAPI filter to also export SymbolServerSetOptions() and SymbolServerByIndex(). My DLL now effectively contained exports similar to symproxy.dll and symsrv.dll. The implementation of the exported functions called through to the real symproxy.dll and the real symsrv.dll.
Since symproxy.dll loaded symsrv.dll using LoadLibrary(“symsrv.dll”) I had to name my DLL SymSrv.dll. To avoid DLL name confusion I renamed the original symproxy.dll to symproxy.orig.dll, and symsrv.dll to symsrv.orig.dll. My shim DLL was named SymSrv.dll, and implemented the symproxy.dll and symsrv.dll exports.
IIS -> SymSrv.dll -> symproxy.orig.dll
symproxy.orig.dll -> SymSrv.dll -> symsrv.orig.dll
I observed that symproxy.dll responds to the ISAPI GetFilterVersion() call and sets pVer->dwFlags to:
// pVer->dwFlags 0x00081203
// SF_NOTIFY_ORDER_HIGH 0x00080000
// SF_NOTIFY_URL_MAP 0x00001000
// SF_NOTIFY_LOG 0x00000200
// SF_NOTIFY_NONSECURE_PORT 0x00000002
// SF_NOTIFY_SECURE_PORT 0x00000001
I observed that the symproxy.dll sets the following options when calling SymbolServerSetOptions():
// SSRVOPT_UNATTENDED 0x00000020
// SSRVOPT_SERVICE 0x00100000
// SSRVOPT_CALLBACK 0x00000001
// SSRVOPT_TRACE 0x00000400
// SSRVOPT_PROXY 0x00001000
I observed that the parameters being passed in to SymbolServerByIndex() are the symbol server, the file name, and an identifier. I also observed that the file name and identifier are present in the URL, but that by the time symproxy.dll calls SymbolServerByIndex() the parameters have all been made lowercase.
The requested URL would look something like:
“/symbols/ch/chrome_exe.pdb/A931F873616F40A4972373FAD37D562D1/chrome_exe.pdb”
The physical path would look something like:
“C:\inetpub\Symbols\chrome_exe.pdb\A931F873616F40A4972373FAD37D562D1\chrome_exe.pdb”
The parameters passed to SymbolServerByIndex() would look something like:
“c:\inetpub\symbols*http://build.chromium.org/buildbot/symsrv”
“chrome_exe.pdb”
“a931f873616f40a4972373fad37d562d1”
Since I had access to the original path request, and I could intercept the call to SymbolServerByIndex(), I wrote code to replace the file name and identifier with the original cased versions.
See the source code for details.
This fixed the case problem and I was now able to retrieve symbols from the Mozilla and Firefox symbol servers.
This did not however solve the problem with the Microsoft symbol servers.
This worked:
symchk.exe “notepad.exe” /v /s “srv*c:\symbols* http://msdl.microsoft.com/download/symbols”
This failed:
symchk.exe “notepad.exe” /v /s “srv*c:\symbols*http://our.symbol.server/symbols”
I captured network stack traces of the direct request and the proxy server request.
Direct request:
HTTP – Hyper Text Transfer Protocol
HTTP Command: GET
URI: /download/symbols/notepad.pdb/DA66AEF719A14FF9902CB3D8EDB248E71/notepad.pdb
HTTP Version: HTTP/1.1
Accept-Encoding: gzip
User-Agent: Microsoft-Symbol-Server/6.11.0001.402
Host: msdl.microsoft.com
Connection: Keep-Alive
Cache-Control: no-cache

HTTP – Hyper Text Transfer Protocol
HTTP Command: GET
URI: /download/symbols/notepad.pdb/DA66AEF719A14FF9902CB3D8EDB248E71/notepad.pd_
HTTP Version: HTTP/1.1
Accept-Encoding: gzip
User-Agent: Microsoft-Symbol-Server/6.11.0001.402
Host: msdl.microsoft.com
Connection: Keep-Alive
Cache-Control: no-cache
Proxy server request:
HTTP – Hyper Text Transfer Protocol
HTTP Command: GET
URI: /download/symbols/notepad.pdb/da66aef719a14ff9902cb3d8edb248e71/notepad.pdb
HTTP Version: HTTP/1.1
User-Agent: Microsoft-Symbol-Server/6.11.0001.402
Host: msdl.microsoft.com
Connection: Keep-Alive
Cache-Control: no-cache
Pragma: no-cache
The problem turns out to be that the symbols on the Microsoft symbol server are compressed, and that the client would ask for the PDB file, get a 404, then ask for the compressed PD_ file, while the proxy would only ask for the PDB file, get a 404, and do nothing.
By reverting symproxy.dll and symsrv.dll back to version 6.8.0.4, the symbol proxy worked again, first asking for the PDB, then asking for PD_, then decompressing the PD_ to PDB, and serving the PDB to the client.
While looking at the meaning of the various options passed to SymbolServerSetOptions() I recalled that the MSDN documentation stated that the SSRVOPT_SERVICE option had been deprecated. I took a chance and modified my code to prevent the SSRVOPT_SERVICE option from being set.
The result was that the symbol proxy now correctly retrieved compressed symbols.
I now have a working symbol proxy that fixes the problems experienced with case sensitive web servers and compressed symbols.
The source code is available here, normal disclaimers apply, use at your own risk.
Installation instructions:
– Rename the original symproxy.dll to symproxy.orig.dll
– Rename the original symsrv.dll to symsrv.orig.dll
– Compile the code for your platform and copy SymSrv.dll to the same location as symproxy.orig.dll
– The ISAPI registration will now point to the new SymSrv.dll file
Testing the code:
– The simplest way to test is to run IIS in debug mode
– To run IIS in debug mode you must run VC elevated
– Set the debug target to “C:\Windows\System32\inetsrv\w3wp.exe /debug”
– Change the ISAPI registration to point to your build output SymSrv.dll
– Make sure that the WWW service is not running
– Start the debugger, this will start IIS, access the symbol server, this will load the ISAPI DLL
My solution is pretty much a hack, and since I do not have documentation for SymbolServerByIndex(), I assume there may be some use cases where my code will break.
Microsoft has acknowledged the problem, and said they will fix the two problems in the next Debugging Tools for Windows release.
Maybe one day Microsoft will make all their utilities open source allowing the community to fix problems instead of working around them.

Installing Vista SP1 with an OEM key

I received my new Lenovo ThinkPad T61 notebook, pre-installed with Vista Ultimate, but also with 3rd party software I did not care for.

I wanted a clean Vista install, and that is exactly why I made sure to order the recovery media with the notebook, thinking that this will include an OS install DVD. It turns out that the recovery media is six CDs, I don’t know why not a DVD, regardless, the recovery media does not include a Vista install DVD.

I called Lenovo support asking how to obtain a Vista DVD that will accept the OEM key, and was told that Vista install DVDs are not available, and that I should use the recovery CDs or the recovery partition.

I decided to give the recovery partition a try; boot, press F11, select restore, do a custom restore, unselect all the 3rd party software, start the install process.

The machine rebooted several times, eventually returning to the same state as when I first booted. There was no 3rd party software on the system, only the Lenovo ThinkPad software was installed.

This was much better than the out of the box version, but still not as clean as I’d like it to be.

I did some research and found several articles explaining elaborate procedures on how to install Vista using a normal Vista DVD and an OEM key.

Since I had read that Vista SP1 had made some licensing changes, I decided to experiment using a Vista x86 with instegrated SP1 DVD I downloaded from MSDN.

I was not sure if I would need the actual key used on my system, as explained by the article, which is different to the key on the OEM sticker, so to be safe I used Magical Jelly Bean Keyfinder to make a note of my current key. This key was indeed different than the key on the OEM sticker.

I booted from the Vista with integrated SP1 DVD, formatted the partition, it was interesting that the 6GB recovery partition does not show up in Vista, I did not enter a key, and started the installation.

After the installation completed I changed the product key using the key I had previously retrieved from the system. After a few seconds Windows reported that there was a problem with the key.

This is when I noticed something interesting, the activation window appearance changed, and the temporary key that was displayed changed to indicate xxx-OEM-xxx. It seems that Windows automatically switched to OEM mode.

Next I tried the key on the sticker, and after a few seconds Windows was activated.

I was intrigued by the automatic mode change, but I did not want to repeat the whole procedure just to find out if I could have used the OEM key in the first place.

If you try this procedure using Vista with integrated SP1, be sure to first try the key on the OEM sticker, you may not need the initial key retrieval step at all.