Category Archives: Windows

Re-enabling desktop effects in Windows 7

Every once in a while, Windows 7’s Desktop Window Manager (DWM) spontaneously goes funky on me and loses its effects (transparency, blurring, shadows).

When this happens, you can get your effects back by going to Services and restarting the “Desktop Window Manager Session Manager” service, or by going to an Administrative command prompt and running:

net stop uxsms
net start uxsms

Getting started with Windows kernel development

I’m diving into Windows development here in MSR Redmond’s OS group. I have mainly a Linux background and know much less about Windows, so I’ve been taking notes. I’ll be publishing an assortment of these notes/tips. Today I’ll talk about kernel-mode development and debugging basics.

Windows kernel module/driver binaries are .sys files (like .ko files on Linux), which may be accompanied by a .pdb file containing the debug symbols for the binary. Kernel Programming 101 is a nice introductory tutorial on how to write and build these drivers, but the section on loading them manually by editing the registry doesn’t work in Windows 7 (perhaps this was XP-and-earlier). You should use the DriverLoader tool from OSR Online to register your driver as a service and start it; it probably uses the Windows API to accomplish this. By the way, OSR Online is a useful website and community for Windows kernel hacking that puts out other tools as well.

windbg (“windbag”) is a handy multi-purpose debugger, included in the Windows Driver Kit. It used to be a userland-only debugger, whereas kd was the kernel debugger, but all debugging functionality has been merged into one place, used by both windbg and ntsd. ntsd is a command-line debugger, whereas windbg has a GUI and a bunch of other nifty features, such as the ability to pull symbols (those .pdb files) and sources automatically from symbol servers and source servers. I used to use windbg to analyze those crash dumps that are produced whenever you get a BSOD; the stack trace may provide hints as to the source of the problem.

In the 64-bit versions of Windows Vista and Windows 7, you can normally only load signed drivers. To disable this requirement, start Windows in debug mode. Typically you’ll want to debug a Windows environment running in a VM like Virtual PC. To debug Windows over the virtual COM serial port, the first step is to run the following from an Administrator cmd and reboot:

bcdedit -debug on
bcdedit -dbgsettings serial debugport:1 baudrate:115200

bcdedit is a program that edits boot settings, which once upon a time were configured in a file called boot.ini. There are alternative instructions on the web mentioning other things to try with bcdedit, which I haven’t looked carefully at, but if you’re doing kernel development then you may want debugging mode turned on anyway.

The next step is to go to your VM settings and configure the COM1 port to map to a named pipe, \\.\pipe\<pipe name>. Now you can start the debugger:

set _NT_SOURCE_PATH=SRV*;
set _NT_SYMBOL_PATH=srv*c:\syms*\\symbols\symbols
windbg -k com:port=\\<vpc_host_machine>\pipe\<pipe name>,pipe,resets=0,reconnect

The environment variables tell windbg about the servers from which to automatically pull symbols/sources; you’ll need to adjust this, since \\symbols\symbols is a Microsoft-internal share. resets=0 is required for Virtual PC; use resets=2 for a competing VM product. reconnect waits for a named pipe if it’s not found on the target and waits to reconnect if disconnected. vpc_host_machine is the name of the host running the VM; if you’re debugging locally, use \\.\pipe\<pipe name>.

Side note: symbol files contain information about variable and function names. Public symbols include globals, while private symbols include everything else (locals, structs, etc.). Full symbol files contain both, whereas stripped symbol files contain just public symbols. Microsoft’s Internet symbol server is at http://msdl.microsoft.com/download/symbols. To use it, you can just leave the symbol server variable alone; I believe the default behavior is to use this public server. (I also believe the .symfix windbg command without arguments restores the default symbol path.) In my case, to also allow symbols for my own driver to be resolved, I needed to set the symbol path to the following:

srv*c:\syms*\\symbols\symbols;C:\Users\...\mydriver\objchk_win7_x86

To break down what just happened: the symbol path syntax consists of multiple semi-colon-separated paths, each of which can be a local path, a cache, or a symbol server. Here are some example components:

cache*C:\syms

uses C:\syms as a cache for all components to its right.

srv*http://symserver/symbols

uses http://symserver/symbols as a symbol server. This can also be a share, i.e. \\symserver\symbols.

srv*C:\syms*http://symserver/symbols
cache*C:\syms;srv*http://symserver/symbols

are (I think) equivalent, and use C:\syms as a local cache for symbols from the remote symbol server. You can specify any number of cascading intermediate caches:

srv*C:\syms*\\symcache\symbols*http://symserver/symbols

When debugging issues with symbols, use !sym noisy to enable verbose symbol debugging info.

The source path is used differently. I’m not sure how source lookup works for built-in Windows modules, but when debugging your own drivers, the .sys and .dll files themselves contain the full local paths to the source files, so that you can list and step through your code out-of-the-box if you’re running windbg from the same machine where you built.

Anyway, back to actual debugging: you can attach to the system by restarting the VM. Note that windbg can only attach when the system starts up; you can’t attach to a running system. Once you’re in the debugger, you can hit ctrl-break to immediately break the target machine. You can try setting a breakpoint with bp, e.g., bp nt!NtReadFile. The word before the ! is the name of the module/driver (in this case we’re addressing the kernel), and the word after it is the name of the subroutine to break in. Your symbol path must be set up correctly to resolve these function names to addresses. You can also set breakpoints in your own driver, such as with bp mydriver!DriverEntry. It’s OK to set this before the driver is even loaded; bp will automatically behave like bu, which creates an unresolved breakpoint, to be resolved once the matching module is loaded. Note that if you update your sources while they’re open in windbg, you must close the file to refresh it.

To continue, enter g. Play around with the debugger, and consult the documentation – the WDK is well-documented.

Windows 7 non-impressions

I’ve been using the free beta release of Windows 7 on my Lenovo X41 Tablet, and during this time I’ve found that I really don’t need that many local applications installed. It’s nice and simple, and everything runs smoothly and quickly (most notably, suspend/hibernate). No IBM/Lenovo software accessories or manually installed device drivers to set up or get in the way. I think the only thing which I could imagine missing is the IBM accelerometer-based hard disk protector.

I installed the system by blindly following these instructions to create a bootable USB from the DVD ISO under Windows XP (most instructions assume Windows Vista or Windows 7). The only hitch during setup was that the system doesn’t have out-of-box support for my Intel PRO/Wireless 2200BG network adapter; I needed to run Windows Update over an Ethernet cable first. Another annoyance, but unrelated to Windows 7, was that I had to defragment my (NTFS-formatted) partition some ten times over before I could ntfsresize it (with an Ubuntu live USB) to make space for Windows 7.

Here’s the shortlist of applications that I actually installed:

  • Chrome: “mostly-FLOSS” browser of choice

And that’s it! No Java. No IM or email client—these run on my main desktop, but even if they didn’t, I’d just use Gmail/Meebo/etc. No IDE or dev tools—I do most of my development over SSH. No office suite—I just don’t use these applications much anymore, and probably also because I’ve moved most of my document authoring to LaTeX or Pandoc or what have you. I imagine I’ll be crawling back to Powerpoint 2007 once I have to crank out another presentation, though—it’s just easy, fast, and pretty.

I didn’t even need to download the Consolas font, since it’s included in Windows 7.

Over time, I can imagine myself also installing the following:

  • Vuze: downloading media wirelessly may be safer, and Vuze is still the best BT client with features that matter (faster downloads, resilient tracking, search); goes well with PeerGuardian

I thought I’d have more to say about Windows 7 by this point, but I honestly still haven’t experienced it that deeply. (The fact that it’s out of my way is just as well a Good Thing, but where’s the fun in that?) That, plus the fact that I don’t have many local apps, lets me realize first-hand that the significance of the laptop/netbook OS is becoming marginalized, and that Chrome OS/Android/Linux really could become relevant. The paradox is that native mobile device apps—like those written for the iPhone OS—are popular and preferred over their web counterparts, and I think that has more to do with generally less-connected usage of these devices and the not-quite-as-slick UI of most web apps.

I elected to try Windows 7 primarily for fun, but also to keep at least some part of myself familiar with the dominant desktop OS of the world, and lastly because it just has better tablet support, battery life, and suspend/hibernate compared to my prior experiences with Linux on the laptop.