









 |
SETUP INSTRUCTIONS FOR WINDOWS OS INTERNALS LABS
Send questions to daves@solsem.com
BASIC SETUP:
- Any 32-bit or 64-bit Windows client or server installation (Windows
7/Server 2008 R2 or
later is strongly preferred - if you use XP or Server 2003 there will be several experiments that won't
work)
- One computer can be shared by 2 students, but 1 per student is better
- The account that you will log into must be a member of the local
administrators group and have the Debug Programs privilege
- Internet access is NOT required if all the setup is done ahead
of time AND you are 100% sure that the necessary symbols are
downloaded (steps 14-18).
IF YOU USE BITLOCKER SUSPEND IT!
Since in class you will be booting in debugging mode
and changing system configuration settings,
if your system drive is encrypted by Bitlocker and you don't suspend it
(on Vista, you can only disable it), you will be prompted to enter your
recovery key on reboot. On
Windows 7 and later you can easily and quickly temporarily suspend Bitlocker on the Bitlocker control
panel page as shown below and then re-enable it after class:

Just as a precaution, make
sure your recovery key is readily available (should not be needed if you
suspend or disable Bitlocker before booting in debugging mode).
OPTIONAL: RUNNING THE EXPERIMENTS IN A VIRTUAL MACHINE
NOTE: Labs are nondestructive (except one lab in
the crash dump analysis section, which you can choose to skip during
class), but can be done in a virtual machine (even on a Mac) if you
prefer.
If you will run Windows 8 or a recent version of
Windows Server, you can use the built-in Hyper-V support. For Windows 7
and older versions of Windows you can use one of Microsoft's free Virtual PC
products (can only run 32-bit OS's):
Or you can use one of these VMWare products (allows
installing 32-bit and 64-bit guests):
There are other freeware virtual machine products
as well (e.g. Virtualbox).
If you don't have a
licensed copy of Windows to install in the virtual machine,
you can download and use evaluation versions or ready to go VHDs (virtual hard disks) for
XP,
Server 2003,
Windows 7,
Server 2008 R2
(VHDs) or
Server 2008 R2 with SP1 (ISO),
Windows 8 Enterprise or
Windows Server 2012.Note: since Server
2008 R2 and later is only available in 64-bit form, you cannot use Microsoft Virtual PC or
Virtual Server - but you can run it under Hyper-V, VMWare, or VirtualBox.
TOOLS SETUP:
- Install the Debugging Tools for Windows and Windows Performance Toolkit
(part of the Windows SDK):
see
http://msdn.microsoft.com/en-us/windows/hardware/gg463009
NOTE:
Microsoft employees: install the Debugging Tools from
http://dbg
and the Windows Performance Toolkit from
\\ntperformance\tools\xperf\msi\latest
You do NOT have to install the entire SDK - when
the SDK installer starts, just select two options, Windows Performance
Toolkit and Debugging Tools, as shown below:

- Download and unzip the Sysinternals tools suite (this is a single zip
file with the majority of the Sysinternals tools). The class notes assume
they are unzipped to c:\sysint, but you can put
them anywhere you choose:
http://technet.microsoft.com/en-us/sysinternals/bb842062
(Microsoft employees can get the latest unreleased version at
\\redmond\files\SYSINTERNALS\LBI\Latest\)
- Download and unzip to c:\sysint the Blue Screen Screen Saver (the one tool not
included in the Sysinternals Tools Suite):
http://technet.microsoft.com/en-us/sysinternals/bb897558
- Download and unzip to c:\sysint the tools that are referenced by the
book Windows Internals:
http://download.sysinternals.com/files/NotMyFault.zip
http://download.sysinternals.com/files/TestLimit.zip
http://download.sysinternals.com/files/AccVio.zip
http://download.sysinternals.com/files/iopriority.zip
- Download and unzip http://www.solsem.com/solsem.zip into c:\solsem (these are additional
files and tools used for various demonstrations and labs)
- If you are running Vista or later, download these tools
by Alex Ionescu and unzip into c:\solsem
(again, these tools do not run on XP or 2003):
http://www.winsiderss.com/tools/winsiderss-tools.zip
- Go to the Startup and Recovery Settings (right click on Computer, click
Advanced system settings, on Advanced Tab, click "Settings" under Startup
and Recovery). Uncheck "Automatically restart" and make sure dump type is
"Kernel memory dump" (not minidump).
- Add a system-wide environment variable for the symbol path:
- Right click on My Computer->Properties, click on Advanced Tab
- Press Environment variables button
- Press "New" button under System Variables section and enter:
Variable name:
_NT_SYMBOL_PATH (must be
upper case) Value for non-Microsoft
employees: srv*c:\symbols*http://msdl.microsoft.com/download/symbols
For Microsoft
employees: srv*c:\symbols*http://symweb
If you are running an interim build that does not have symbols on the symbol
server, please add the symbol location to your symbol path. Find the build
directory at \\winbuilds\release\winmain
(or other directory, if it's taken from another build lab). From that
directory, find the version you installed. Then open "symbols.pri" under
that directory.
For example,
\\winbuilds\release\winmain\7071.0.090326-1750\x86fre\symbols.pri NOTE!
It is not necessary to download and install the symbols - please use the
symbol server (configured above) to automatically download symbols as
needed. For more information on symbols, see
http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx
(or for MS internal, http://dbg)
- If XP 32-bit (5.1 kernel) or earlier, run Gflags (in the Debugging Tools
folder) and enable pool tagging, press Apply, then OK, and reboot (not
necessary for XP 64-bit, Server 2003, Vista, or Server 2008).
- Enabled crash from keyboard:
For a PS/2 keyboard (which includes most laptops), run one of two .REG files in Solsem.zip:
- crashon-rightctrl-scrlk-scrlk.reg (default keystroke sequence: hold down
right control button and press Scroll Lock twice)
- crashon-right-alt-space-space.reg (alternate choice: hold down right ALT
button and press space bar twice)
For USB keyboards (may not work in
all cases), run this .REG file from Solsem.zip: crashon-usb-keyboards.reg
For details, see this
KB article.
- (Optional in IT Pro class - not needed for developer class) Run \Solsem\Logonhlp.reg and copy \Solsem\Logonhlp.exe to
\Windows\System32 (or whatever %Systemroot% is on
your system)
- KERNEL DEBUGGING: Many experiments in the class use the kernel debugger to inspect
internal system state. You can either use the built in ability to do local
kernel debugging (which on Vista and later requires booting in debugging
mode) or use the
Sysinternals LiveKD tool. There are some commands that may
fail in
LiveKD, but for the most part it is fine for class use.
Whichever
you choose, please test in advance that you can perform kernel debugging
(requires the Debug privilege, normally granted to administrators).
LIVEKD: Open an
elevated command prompt and set your current directory to the Debugging
Tools (for example, C:\Program Files\Debugging Tools, or C:\Winddk\7600.16385.1\Debuggers, or for Microsoft internal debugger installations, C:\Debuggers).
Then
from the command prompt, run Livekd from the Sysinternals folder with the
-w switch, e.g. "\sysint\livekd -w". This will launch Windbg in a way that
lets you use kernel debugger commands to inspect system state (note: LiveKD
uses a trick such that the debugger thinks it is looking at a crash dump,
when in reality it is reading actual system memory).
LOCAL KERNEL DEBUGGING:
You must boot in debugging mode - either press
F8 during the boot process and choose Debugging Mode from the list of
advanced boot options or configure the system to boot automatically in
debugging mode (either run MsConfig, click on the Boot tab, then click the Advanced Options
button, then check Debug or from a command prompt type "bcdedit /debug
ON").
To confirm you successfully booted in debugging mode,
from a command prompt, execute the run the kdbgctrl.exe tool in the
Debugging Tools folder with the "-c" (check) switch.
There is
an odd case where enabling debugging still does not permit kernel debugging
- try the workaround on
Alex's blog.
REMEMBER IF
YOU ARE USING BITLOCKER TO SUSPEND OR DISABLE IT BEFORE BOOTING IN DEBUGGING
MODE (see note at top).
NOTE FOR SKYPE USERS:
If you run a program that performs a user mode debug breakpoint (like
Skype does) while booted in debugging mode, your system will freeze - to work around this, you need to
disable user mode exceptions (or just disable Skype from running
automatically before you reboot in Debugging Mode). To do this, boot in
debugging mode, open an elevated command prompt, go to the Debugging Tools
folder, and type "kdbgctrl -du". This disables kernel debugger user
mode exception handling. However, this takes effect only for the current
boot. To configure the system to do this permanently, type:
bcdedit /debug on bcdedit /dbgsettings
debugport:1 baudrate:115200 /noumex
Once you have booted in debugging mode, run Windbg from the
Debugging Tools (on Vista and later must be run elevated). Then click on
File->Kernel Debug, click on Local tab & click OK. If symbols are configured
properly, a command window should open up (if the command window does not
appear, click View->Command). There should not be any symbol errors for the
kernel symbol file (Ntoskrnl.exe).
- Test kernel debugging (these steps apply whether you choose to use
LiveKD or Local Kernel Debugging):
- Type "!process" in the Windbg command area to make sure symbols are
loaded and configured. If this command fails, you have symbol issues.
Again, if the command window does not appear, click View->Command.
- Force the download of other kernel symbol files to your local
symbol cache (typically c:\symbols) by typing ".reload /f"
(if you are sure that you will have network connectivity during the class, you can
skip this step and let the
symbols download on demand as they are referenced during the class).
NOTE: It is normal to get symbol loading errors for
third party device drivers, as their symbols are not available on the
symbol server.
- Configure symbols for Process Explorer and Process Monitor
Run Process Explorer and Process Monitor. In both tools, click on Options->Configure Symbols.
Change the Dbghelp.dll path to reference the one in your Debugging Tools folder and
make sure the correct symbol path
is set. NOTE: you cannot use the
Dbghelp.dll in \Windows\System32 as it does not support the symbol service; you must use the one in the Debugging
Tools folder.
An example configuration dialog (for a 64-bit system) using public symbols
would be:

- In the Process Explorer's list of processes, double click on the process
called "System" (usually 4th in the list) and click on the Threads tab
(there may be a delay while symbols are downloaded).
When the list of threads are displayed, to confirm symbols were downloaded
properly, sort by the Start Address column and scroll down until you see
threads with start addresses in the form "ntoskrnl.exe!xxx" or ""ntkrnlpa.exe!xxx"
- make sure you do NOT see any "+0x" after any of these entries. This
is an example of a correct output:

If you see entries like "ntoskrnl.exe!yyyyyy+0xnnn" for most
of the Ntoskrnl/Ntkrnlpa lines, then your symbols are not configured correctly. For example, this kind of display indicates kernel symbols are
NOT correctly configured:

- Finally, double click on several other processes to force the download
of other user mode symbols: Explorer.exe, a few Svchost.exe processes, Csrss.exe, Winlogon.exe,
etc. The reason for doing this is to get a variety of other user mode
.EXE symbol files
cached on your machine for use during the class. After doing the above, you
should see a number of subfolders under c:\symbols -- these folders contain
symbols for the various images referenced.
|