kichik’s blog

Microsoft provides useful extensions for debugging SCSIPORT drivers in WinDbg. But with some versions of scsiport.sys, the symbol files don’t contain type information. This produces fun errors like the following.

kd> !scsikd.scsiext 8a392a38
*************************************************************************
***                                                                   ***
***                                                                   ***
***    Your debugger is not using the correct symbols                 ***
***                                                                   ***
***    In order for this command to work properly, your symbol path   ***
***    must point to .pdb files that have full type information.      ***
***                                                                   ***
***    Certain .pdb files (such as the public OS symbols) do not      ***
***    contain the required information.  Contact the group that      ***
***    provided you with these symbols if you need this command to    ***
***    work.                                                          ***
***                                                                   ***
***    Type referenced: scsiport!_DEVICE_OBJECT                       ***
***                                                                   ***
*************************************************************************
scsikd error (3): ...\storage\kdext\scsikd\scsikd.c @ line 188

This makes the common task of getting your device extension object very daunting. After some digging, I came up with this code to at least get my device extension object from SCSIPORT’s device extension object.

!drvobj mydriver
* get relevant DevObj
!devobj <devobj>
* get DevExt
dt mydriver!MY_DEVICE_EXTENSION poi(<DevExt> + b4)

I’ve only tried it on Windows XP SP3. The offset may be different with other configurations. Anyone knows a better way around this? Preferable method would naturally be making scsikd work.

Read more at my company’s blog.

As mentioned in my previous post, I have been working on incorporating some more features into WinVer.nsh. Every little change in this header file requires testing on all possible versions and configurations of Windows. Being the Poor Open Source Developer^TM that I am, I do not have sufficient resources to assemble a full-blown testing farm with every possible version of Windows on every possible hardware configuration. Instead, I have to settle for a bunch of virtual machines I have collected over the years. It is pretty decent, but has no standards and doesn’t cover every possible version. Still, it does its job well and has proven itself very effective.

Obviously, be it a farm or a mere collection of virtual machines, testing on so many different configurations carries with it a hefty fine. Testing a single line change could waste almost an hour. Imagine the time it would take to test, fix, retest, fix and retest again a complete rewrite of WinVer.nsh. As fascinating as that empirical scientific experiment would have been, I was reluctant to find out. Laziness, in this case, proved to be a very practical solution.

WinVer.nsh tests do not really need the entire operation system and its behavior as it relies on nothing but 4 parameters. All it requires is the return values of GetVersionEx for OSVERSIONINFO and OSVERSIONINFOEX. For nothing more than 312 bytes, I have to wait until Windows Vista decides it wants to execute my test, Windows NT4 gracefuly connects to my network, Windows ME wakes up on the right side of the bed and doesn’t crash, Windows Server 2008 installs again after its license has expired and Windows 95…. Actually, that one works pretty well. So why wait?

Instead, I’ve created a little harvester that collects those 312 bytes, ran it on all of my machines and mustered the results into one huge script that tests every aspect of WinVer.nsh using every possible configuration of Windows in a few seconds. It required adding a hooking option to WinVer.nsh, but with the new !ifmacrondef, that was easy enough.

Currently, the script tests:

• Windows 95 OSR B
• Windows 98
• Windows ME
• Windows NT4 (SP1, SP6)
• Windows 2000 (SP0, SP4)
• Windows XP (SP2, SP3)
• Windows XP x64 (SP1)
• Windows Vista (SP0)
• Windows Server 2008 (SP1)

If you have access to a configuration not listed here, please run the harvester and send me the results. More specifically, I could really use Windows 2003 and Windows Vista SP1. My Windows Vista installation simply refuses the upgrade to SP1. Again.

The test script also includes a hexdump of those 312 bytes for every configuration so anyone performing similar tests for another reason doesn’t have to parse the NSIS syntax. Feel free to use it for your testing.

Ladies and gentlemen, we interrupt the silence schedule to bring you shocking news. Hatred has reared its ugly head on the forsaken grounds of our dear old friend — Windows 98. It appears the bigots have set a new target for their cynical and non-politically-correct persecution. Big-boned dialogs and initialization-limited rectangulars are shamelessly discriminated against and abused for no acceptable reason. Exceptions, overflow errors, division errors and antique dialogs were thrown at the victims, reports say. We were unable to get comments from the alleged bigots.

We were unable to get pictures from the event, but luckily, it can be easily reproduced.

BOOL CALLBACK proc(HWND h, UINT m, WPARAM w, LPARAM l)
{
  return FALSE;
}
int main(int argc, char* argv[])
{
  char dt[24] = {0,};
  RECT r = {32757,};
  HWND dlg = CreateDialogIndirect(
    GetModuleHandle(NULL),
    (LPDLGTEMPLATE) dt,
    0,
    proc);
  MapDialogRect(dlg, &r); // BOOM!
  return 0;
}

On every second Tuesday of the month, Microsoft indulges us with a slew updates ranging from trivial to critical and sometimes even truly superior. Sadly, not even the most ardor imbued zealot of Windows rejuvenation can bring the updates to life without a reboot. To ensure everyone do reboot, Microsoft has added the lovely “Restart Now” dialog we have all come to cherish.

Distressing as it may be, while loved and cherished, the dialog is often the center of attention in the Windows loath-fest. Getting rid of it, however, isn’t that difficult. All it takes is killing one service.

net stop wuauserv

But what if yours truly is not near the computer on patch Tuesday and the dialog starts its cheerful countdown to complete and total annihilation of the current session? While skimming through some Group Policies, I’ve noticed there’s one for disabling this annoying reboot countdown. Simply create a DWORD named NoAutoRebootWithLoggedOnUsers under HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU, set it to 1 and say bah-bye to Microsoft’s equivalent of the dreaded ad pop-up.

Microsoft’s Tim Rains has more details on the subject.