This newsletter contains archived content. No warranty is made as to technical accuracy of content or currency of URLs.
The Microsoft Hardware Newsletter provides manufacturers and developers the latest technical details for how to succeed with the Windows platform. Register now, if you're not already receiving the Microsoft Hardware Newsletter.
You arrive at an interesting breakpoint while debugging your driver, only to have the debugger pause for a very long time while it attempts to load symbols for drivers that you don't own and that don't even matter for the debugging task at hand. What's going on?
By default, symbols are loaded by the debugger as they are needed. (This is called deferred symbol loading or lazy symbol loading.) The debugger looks for symbols whenever it executes a command that calls for the display of symbols. This can happen at a breakpoint if you have set a watch variable that is not valid in the current context, such as a function parameter or local variable that doesn't exist in the current stack frame, because they become invalid when the context changes. It can also happen if you simply mistype a symbol name or execute an invalid debugger command--the debugger starts looking for a matching symbol.
What should you do?
| • |
Use qualified names in breakpoints and debugger commands whenever possible.
|
| • |
Activate noisy symbol loading (SYMOPT_DEBUG) to diagnose the causes of slow symbol loading.
|
| • |
Activate SYMOPT_NO_UNQUALIFIED_LOADS to prevent the debugger from searching for symbols in unloaded modules.
|
| • |
Use debugger commands such as .reload or ld to explicitly load the modules you need for your debugging session.
|
A number of options are available to control how the debugger loads and uses symbols. For a complete list, see Setting Symbol Options in the Debugging Tools for Windows documentation.
Tip: Download the latest release of Debugging Tools for Microsoft® Windows®. The current release is version 6.5.3.8 - August 10, 2005.
—Annie Pearson for the WHDC team
|
WHDC After Dark. Here's this week's opportunity to hang out for 10 minutes at the Internet watercooler with the WHDC team:
| • |
Daydreaming Stromberg Carburetors: We at Microsoft are proud when anyone from the home team (well, Fargo branch) wins a world-respected award. Congratulations to Dan McKay!
|
|
Hardware and Driver Design for Microsoft Windows Vista
The WHDC Web site provides frequent updates from the Windows development teams, with guidelines for hardware and driver design to support features in the Microsoft Windows Vista™ operating system.
|
|
Guidelines for developers on how to provide hardware and software support for home theater speaker configurations and multichannel audio stream formats, including both 5.1 and the new 7.1 configurations.
Requirements and implementation details for Consumer and Small Business routers, WLAN access points, and residential gateways for systems that run Windows Vista.
Guidelines for driver developers, BIOS vendors, and system manufacturers on how to implement ACPI support and related support in LDDM display drivers to support communication between the system BIOS and graphics hardware on systems that run Windows Vista.
|
Notes from Windows Developers
|
|
XPS (formerly codenamed "Metro") is the set of conventions that applications and printers can use to describe the content and appearance of paginated documents, based on XML and other widely available technologies. XPS stands for XML Paper Specification. To learn more, watch Windows Vista evangelist Tim Sneath's interview with Jerry Dunietz, an XPS architect at Microsoft.
|
Security and Windows Drivers
|
|
Microsoft Windows Vista provides advances that enable developers to create more secure applications and to ease the burden on system administrators and end users when it comes to securing systems.
Windows Vista changes the traditional Windows privilege model to help prevent users from running programs that attempt to perform operations that the user doesn't really intend or authorize. To that end, User Account Protection (formerly called Least-privileged User Account, or LUA) enables users to run at low privilege most of the time, while being able to easily run applications that require more privilege as necessary. There are two key things to consider when building applications to make use of User Account Protection (UAP): the privilege specification model and the standard UAP execution model.
|
|
Edition for
