Windbg入门与调试技巧：从安装到实战应用

需积分: 15 55 浏览量更新于2024-07-24 收藏 5.08MB PDF 举报

本文档深入探讨了"Application Debugging"这一主题，主要聚焦于Windows应用程序调试技术，特别是使用Windbg工具进行高级分析和调试的方法。作者Hans De Smaele在2004年9月12日发布了这篇内容，涵盖了多个关键点。首先，文章介绍了调试和仪器脚本的基本概念，包括如何利用这些工具进行初步的故障排查和性能优化。读者可以了解到如何通过编写调试和监视脚本来深入理解程序运行过程。接着，章节转向了符号和符号服务器的使用，这是调试过程中至关重要的环节，因为它能帮助解析二进制代码中的函数和变量名。讲解了不同的调用约定，这对于理解和跟踪调用链路至关重要。此外，还讨论了堆栈追踪及其相关主题，这对于定位问题的根源非常有帮助。 "Debugging of 'free builds'"部分着重于处理非正式或未打包的软件版本，可能存在的问题和解决策略。创建和分析崩溃转储文件也是开发者必备的技能，文章对此进行了详细的指导。文章继续介绍如何利用ILDASM和ILASM工具来分析和修改.NET框架下的中间语言（IL），这在深入理解代码结构和优化上十分有用。此外，文中还提到了Windbg的一些扩展功能，以增强调试能力。远程调试是另一个重要主题，它允许开发者在远程机器上诊断问题，这对于分布式系统尤其重要。文章列出了不同场景下的调试需求，并阐述了计算机应用程序生命周期的各个阶段。然后区分了"production debugging"（生产环境调试）与"development debugging"（开发环境调试）的差异，强调了在实际部署中如何调整调试策略。此外，文中还探讨了调试和代码仪器脚本在生产和开发环境中的应用。在安装调试器方面，作者提供了详细的步骤，包括如何在Windows系统中安装和配置Windbg，以及如何运用它来调试VBScript这样的脚本语言。接下来，文章深入剖析了代码诊断工具，如如何预防和解决DLL冲突（DLL Hell）问题。作者通过"ChangeJournal"、模块加载位置分析、GAC（全局 assembly cache）管理和特定工具（如Dependency Walker、Process Explorer、DLL Spy 和 Assembly Binder Log Viewer）来指导读者如何解决这类常见的问题。这篇文章提供了一个全面且实用的指南，涵盖了从基础安装到高级调试技巧，以及如何解决Windows应用程序开发中的常见问题。无论是对初学者还是经验丰富的开发者，都是一份宝贵的参考资料。

systems, replication managers and backup systems. The only problem with the Change

Journal is that there isn't any application that a system administrator can use for it. If you

want to use the Change Journal, you have to write a tool for yourself. An example of such

a tool is on the MSDN Magazine website (http://msdn.microsoft.com/msdnmag). This

example, CJTest, records all the actions you do on a disk.

When the CJTest application is started for the first time on a disk, a dialog is displayed

indicating that a full scan of the disk is required (figure 3.1).

Figure 3.1

The CJTest initial dialog.

Soon, the disk is scanned and the Change Journal is active now. To show how it works, a

folder and file are created, modified by Notepad, and deleted again (figure 3.2).

Figure 3.2

Some commands to test the Change Journal's functionality.

Each time a command is given, the Change Journal gets updated, and this is displayed in

the CJTest application (figure 3.3 below).

Of course, you don't need to keep an application like CJTest running on your desktop all

the time. As soon as you activate the Change Journal, it will stay active until you

deactivate it. Together with CJTest comes another sample, CJDump, that shows you how

to list all the records that were recorded by the Change Journal.

So, the Change Journal doesn't prevent you to install a DLL or other file, but at least it

keeps a log about the files and folders that are created, deleted and modified. This,

together with Auditing enabled on your W2K OS, will give you a lot of information that you

can use to find out why an application doesn't work anymore after the installation of

additional files.

Note: The Change Journal doesn't give information about the content of a file. Only

information about creation, deletion or changes are recorded.

Figure 3.3

The Change Journal data, displayed in CJTest.

What kind of DLL Hell can we encounter ?

If, despite our circumspection, DLL Hell occurs, the first thing you should do is to define

what kind of DLL Hell is occurring. The different kind of DLL Hell that can come across

are :

● A DLL is replaced (overwritten) by an older version of the same DLL. In this case

you get a message, telling that one or more functions that the application is calling,

don't exist anymore. This is the easiest kind of DLL Hell : just replace the old

version with the newer version of the DLL.

● A new DLL has functional modifications, when compared with the previous version.

This happens when the new DLL is not 100% backwards compatible with the

previous version. In this case, the different versions of DLLs must be installed side

by side. In this scenario, every application 'gets' his own DLL in the same folder as

where the application is located. A .local file can be used if needed (see later). This

kind of DLL Hell can be difficult to find, also because it doesn't lead to a program

crash all the time (also called a hard fault). Sometimes only the output of the

application is influenced (soft fault) and it can take a long time before this kind of

problem is even noticed.

● The ordinals in the new DLL don't match the ordinals in the previous version. This

is a situation that rarely occurs and the solution for this is also the side by side

installation of the DLL versions.

From where are DLL's loaded ?

Since there have been so many problems with DLL Hell, Microsoft has done a best effort

to overcome these problems, starting with the Windows 2000 operating system.

However, you must understand how DLL's get loaded by applications before you can

choose the best approach to solve the problem. The way the OS Loader looks for (and

finds) a DLL is :

1. The folder where the application is stored that will use the DLL.

2. The current, working directory for this application.

3. The Windows System folder

4. The Windows folder

5. The folders found in the path environment variable.

Application debugging in a production environment

Version 1.1

A fourth way to influence the way a DLL is loaded, is by using a file with the same name

as the executable program, followed by the .local extension. This file must be put in the

same folder as the executable. When the loader sees this file, all DLL's and COM

components are loaded from this folder.

Thanks to all this, there is always a technique that can be used to undo the effect of DLL

Hell. It is always possible to make sure that the application loads the right DLL.

The Global Assembly Cache.

.NET applications avoid the usage of native DLL's (unmanaged code). In .NET,

assemblies are used. One such an assembly can consist of one or more files that make

together a logical group. Each such an assembly consists of compiled code and a so

called manifest file. An assembly doesn't need to be registered, as opposite with COM

components. The assembly is placed in the same folder as the application that is using it

and is then called a private assembly. If the assembly should be used by more than one

application, it is placed in the Global Assembly Cache (GAC).

An application will use the right assembly, because it uses the assembly it was bound

with during the compilation / linking process, and by using the content of the manifest file

that accompany the assembly.

1. The search algorithm a .NET application is using, is :

2. The application path

3. The 'Bin' folder below the application path

4. The folder that has the same name as the assembly, below the application path

(for example : the assembly SAI.DLL can be found then in C:\MyApplication\SAI).

5. The Global Assembly Cache.

The DLL Hell problem in the GAC is solved by the .NET runtime, using the version

information that exist for the assembly. This version number consist of :

● Major number

● Minor number

● Revision number

● Build number

Placing the assembly in the GAC can be done by using the program GACUTIL.EXE or by

dragging and dropping the assembly into the GAC. The GAC itself can be found under

the system folder in %SystemRoot%\Assembly. Several versions of an assembly can be

placed 'side by side' into the GAC, and an application can choose what version it will use

by using a configuration file. What you see, using the explorer, is an hoax. Indeed, it is

impossible to place two (or more) files with the same name in the same folder. A special

template shows the assemblies in the GAC in such a way that it seems that they are

installed in the same folder. The exercise below explains this whole process in detail.

Working with assemblies in the cache.

In this exercise, a small assembly is made (SAI.DLL) that is consumed by an application

(SAITest.exe). The code for the assembly is, written in C#, is very simple. There is only

one method inside the assembly, SayHello(), that isreturning a string that gives version

information.

The first time, we'll give the string as value : Hello from version 1.0. Then, we put this

assembly in the GAC. After that, we make an application that is calling this method. As

you may expect, the program will display a message that returns the string value.

Application debugging in a production environment

Version 1.1

剩余124页未读，继续阅读

MaDashu

粉丝: 0
资源: 1

Windbg入门与调试技巧：从安装到实战应用

Debugging Application (John Robbins 2000)

Debugging Application 应用程序调试技术 光盘

S32DS如何运行例程代码

chrome启动remote-debugging模式

To display the conditions report re-run your application with ‘debug‘ enabled.

To display the conditions report re-run your application with 'debug' enabled.

Cannot This application has no explicit mapping for /error, so you are seeing this as a fallback.resolve symbol 'SpringBootApplication'

console application

debug info warn error fatal

最新资源

Debugging Application 应用程序调试技术光盘