Keeping it tight

The joy of owning a sports car can be decreased with little problems inherent to high performance machines.
One of those little issues with the Lotus Elise (and Exige) is that the stock motor mounts are just too soft, thus there can be a lot of movement while driving. For street driving it's not much of a concern although it can cause some parts to break but when driving on the track, the engine movement increase the risk for problems to arise.

Having those soft mounts will cause the car to have not so crisp shifting and the driver might end up missing some shifts. Also, it may cause the exhaust pipe to break in some place because there's just too much movement and not enough flex from the pipe or the headers.

A solution to those problems is to install  stiffer engine mounts.

I opted for the Innovative mounts from Sector111 because I've got a bunch of stuff from them and it's always been of good quality.

Here's a short description of the product from S111:

Less motor rotation = Improved Shifting & Throttle Response

• Less opportunity for miss shifts
• Great throttle response
      -mid corner control is significantly better
• Less exhaust system stress
      -less exhaust system breakage leading to replacement

All in all, this is a pretty good investment and is something that people serious about driving their Lotus on the race track should consider.

Those things should get installed sometimes next week during some other work I need to get done on the car (Suspensions bushings replacement, air conditioning delete, belt change, mounts).

I'll update this blog once I've been able to test the car with the mounts installed.

Update:


I just got the car back tonight at 6PM from Suspension Performance (in Mountain View). Eric, the owner told me that initially, the car would vibrate a little more but after some 300-400 miles, I would have forgotten about it altogether so, we'll see.

'Vibrate a little more', eh... Well, that's an understatement. I got in the car, snapped the harness on and fired up the engine. The first thing that came to my mind what that there must have been some sort of earthquake at the exact same moment! what a coincidence!

I drove away from the shop and got onto 101 South to end up on 85 South. The vibrations are actually not as bad while driving above 20MPH and it got really noisy but the exhaust gets extra noisy some times, usually at night time for some odd reason. Seems like when the temperature is colder, the thing just drones a lot more. No biggie.

Anyway, as I got close to home and into the streets, the vibrations where in fact not as noticeable as an hour before. I suppose that, like pretty much everything, there is a 'break-in' period and it should be a little smoother with time.

The shaking aside, I did notice a definite improvement in the shifting. It is crispier, just like they say on the S111 web site so it's not just commercial fluff. It seems to help keeping the car a little more stable as well because the motor doesn't move around as much and I can't wait to try it out on the track, hopefully on the 19th or the 20th at Thunderhill.

In addition to the engine mounts, Eric replaced some of the suspension bushings as they were a little tired (the motor mounts, by the way, were shot for the most part). The stock bushing tend to get a beating on the race track and while they were not is a horrible shape, changing them now was definitely a good thing.

The last part, which he could not do was to remove the whole air conditioning bits. I don't use the A/C (the car is a convertible...) and that stuff weights a lot. The problem was that the belt that he received from Lotus was too long and thus, he could not remove the A/C compressor. He should be able to do it next week though. The car will be happy and feel like it's been on a diet.

All in all the motor mounts are a good investment.

Quick WinDBG tricks

Access denied

Who's never been annoyed to see a message such as this one during a debugging session:

fatal error LNK201: error writing program to database 'c:\...\mymodule.pdb'; check for...

Right?

This usually happens when you are working on a driver or even an user mode application while doing some debugging via WinDBG.
Basically what the problem is that, windbg will open the symbol file for your module (.pdb) without shared access.

If it's a driver, you could simply unload the driver from memory, but for an user application, the debugger sometimes retains the lock on the symbols file.

In WinDBG, to remediate the issue, just type: .reload -u
You can them resume running your VM and VC++ will be able to compile your program.

Which brings me to another trick related to VMWare and kernel debugging.

Break-in

Sometimes you need to pause the VM and attach to a process or check some parts of the memory or whatever. In that case, most people will just click the 'Break' button or do a CTRL-BREAK in the UI. This can take a small amount of time and is not always instant.

In order to do this in a bit of a faster way, is to push the 'Print Screen' key while you have grabbed the input inside the VM. This will force WinDBG to break into the running VM and you'll be able to do whatever you want.

Attaching to a process while kernel debugging

Here's an interesting one...
There are some times when you need to attach to a process while inside a kernel debugging session, but the commands may not be all that intuitive to use.

First, break into the VM runtime (See above).
Then, list the processes and pick the one you want to debug with !process 0 0
This will return something along those lines (more than the one entry I showed here):

PROCESS 848f5d40    SessionId:  1 Cid:  016c    Peb: 7ffdf000  ParentCid:  06a0
       DirBase:  35aaf000  ObjectTable:  9f6a3ad8  HandleCount:  118
       Image:  taskmgr.exe

To attach to that process: .process /i 848f5d40
The /i basically mean that you want to go into interactive mode and the number is the process handle.
The debugger will then tell you to press 'g' <enter> to continue. Which you will oblige thus, sending you into the context of the process. You may now debug at your leisure.
In order to verify that you are where you want to be you can type: !peb

Signing your driver

Here I'm going to discuss how to sign your (awesome) driver.

You could just go to MSDN and download the .DOC file that describes how to do it but it may take a while before you can actually get it to work. Also, the document has been written a while ago and some of the stuff is a little out of date.

So, to make it a bit easier, I am going to give a sequence of commands to run in order to sign your stuff.

All the following is executed from:

/Projects/Sandbox/Manu/mydriver/

--- Creating the self cert ---
makecert -pe -ss PrivateCertStore -n CN=mycompany.com -r mycompany.cer

--- Add the cert to trusted root ---
certmgr.exe /add mycompany.cer /s /r localMachine root

--- Create the CAT file ---
inf2cat /v /driver:c:\projects\Sandbox\Manu\mydriver /os:7_X86

--- Sign the cat file ---
signtool sign /v /s PrivateCertStore /n mycompany.com /t "http://timestamp.verisign.com/scripts/timstamp.dll" mydriver.cat

--- Verify the signature and all ---
signtool verify /pa /v /c mydriver.cat mydriver.inf

--- Sign the driver in case the above stuff don't work ---
signtool sign /v /s PrivateCertStore /n mycompany.com /t "http://timestamp.verisign.com/scripts/timstamp.dll" chk_win7_x86\i386\mydriver.sys

Obviously, all those commands are on one line. The formatting on the page forces the line breaks.
The last command may be used to sign the driver (.sys) itself. You may resort to that if the rest of the stuff does not work. Normally what happens is that you create the signature and self certificate and then, you create a catalog file that the .inf refers to. Meaning that you don't have to sign the driver.

The reason you don't want to sign the driver is that when you are debugging it, all you need to do is to copy it into your folder and then, right click the .inf and select the 'install' option. Which, will verify the signature as well as copy the .sys into the proper location.

This is required when developing drivers for 64Bit Windows. Also, the OS should be booted in test mode for the self cert to work. You could also not sign the driver and boot Windows with the ignore option. But what would happen then is that some APIs will no longer be available to you (like for instance: PsSetCreateProcessNotifyRoutineEx).

I have used that with the DDK version 7600.16385.1
Can't garantee that it will work with the previous ones or even later releases but you can always experiment.