iniwf

风是温柔的,雨是伤心的,云是快乐的,月是多情的,爱是迷失的,恋是醉人的,情是难忘的,天是长久的,地是永恒的

Windows程序调试系列文章——Windbg轻松上路

转自http://www.cnblogs.com/itrust/archive/2006/08/18/480692.html

        摘译自 WinDbg the easy way ,Oleg Starodumov

       源码下载:http://files.cnblogs.com/itrust/WindbgEasyWayDemo.rar

      
如果要说最好的调试器是什么?那一定是:Visual Studio + WindbgVisual Studio直观简捷,Windbg强大复杂。在你调试程序的时候,如果使用Visual Studio感觉束手无策时,就该考虑Windbg了,但Windbg是如此的专业,入门是如此的难。有没有更简单轻松一点的办法呢?可以考虑先使用CDBWindbg的姐妹——轻量级控制台程序)。CDBWindbg的命令是一致的,一旦熟悉了CDBWindbg可上手了。

  简介

1.1  环境准备

首先需要通过环境变量_NT_SYMBOL_PATH来配置符号文件的定位,可以从微软的网站上去下载,也可直接指定网站地址,让CDBWindbg需要时自己去找,各自如此设置:

set _NT_SYMBOL_PATH = D:\debug\symbols;D:\debug\WindowsXP-KB835935-SP2-symbols
set _NT_SYMBOL_PATH = srv*c:\symbols*http://msdl.microsoft.com/download/symbols

注意:除了操作系统符号文件的定位,你也需要设置自己的程序的调试信息(*.pdb文件)的定位,如上例中的D:\debug\symbols

1.2      CDB命令行基本用法

选项

描述

举例

-p Pid

告知CDB通过进程号挂接到某个进程

cdb -p 1034

-pn ExeName

告知CDB通过进程的可执行文件名挂接到某个进程。如果当前有多个同名的进程运行,则不能使用该选项(CDB会报错)

cdb -pn myapp.exe

-psn ServiceName

告知CDB通过服务名挂接到某个Windows服务的进程

cdb -psn MyService

1.3      命令行用法汇总

这里列出本文将使用到的命令行,也是CDB的主要用法。

    通过进程号以非侵入模式挂接到进程上,执行一些命令(command1; command2;...;commandN;),然后推出(q,并输出日志文件:

cdb -pv -p <processid> -logo out.txt -lines -c "command1;command2;...;commandN;q"  

打开转储文件,执行一些命令,并打印到日志文件

 cdb -z <dumpfile> -logo out.txt -lines -c "command1;command2;...;commandN;q"

  需要说明一下非侵入模式(noninvasive),可以理解为不打断不影响进程运行的情况下和进程挂接。当然,这种模式下,调试器无法控制程序的运行。

2     实例应用

2.1      调试死锁

下面演示如何通过CDB来找出死锁,请做如下准备工作:

1.        编译DeadLockDemo.cpp

2.        运行编译出的exe,程序会立刻死锁

我们先通过"~*kb命令(显示所有的堆栈信息)看看都有那些线程在运行:cdb -pv -pn myapp.exe -logo out.txt -lines -c "~*kb;q"

. 0 Id: 6fc.4fc Suspend: 1 Teb: 7ffdf000 Unfrozen
ChildEBP RetAddr Args to Child              
0012fdf8 7c90d85c 7c8023ed 00000000 0012fe2c ntdll!KiFastSystemCallRet
0012fdfc 7c8023ed 00000000 0012fe2c 0012ff54 ntdll!NtDelayExecution+0xc
0012fe54 7c802451 0036ee80 00000000 0012ff54 kernel32!SleepEx+0x61
0012fe64 004308a9 0036ee80 a0f63080 01c63442 kernel32!Sleep+0xf
0012ff54 00432342 00000001 003336e8 003337c8 DeadLockDemo!wmain+0xd9 [c:\tests\deadlockdemo\deadlockdemo.cpp @ 154]
0012ffb8 004320fd 0012fff0 7c816d4f a0f63080 DeadLockDemo!__tmainCRTStartup+0x232 [f:\rtm\vctools\crt_bld\self_x86\crt\src\crt0.c @ 318]
0012ffc0 7c816d4f a0f63080 01c63442 7ffdd000 DeadLockDemo!wmainCRTStartup+0xd [f:\rtm\vctools\crt_bld\self_x86\crt\src\crt0.c @ 187]
0012fff0 00000000 0042e5aa 00000000 78746341 kernel32!BaseProcessStart+0x23 
   1 Id: 6fc.3d8 Suspend: 1 Teb: 7ffde000 Unfrozen
ChildEBP RetAddr Args to Child              
005afc14 7c90e9c0 7c91901b 000007d4 00000000 ntdll!KiFastSystemCallRet
005afc18 7c91901b 000007d4 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc
005afca0 7c90104b 004a0638 00430b7f 004a0638 ntdll!RtlpWaitForCriticalSection+0x132
005afca8 00430b7f 004a0638 005afe6c 005afe78 ntdll!RtlEnterCriticalSection+0x46
005afd8c 00430b15 005aff60 005afe78 003330a0 DeadLockDemo!CCriticalSection::Lock+0x2f [c:\tests\deadlockdemo\deadlockdemo.cpp @ 62]
005afe6c 004309f1 004a0638 f3d065d5 00334fc8 DeadLockDemo!CCritSecLock::CCritSecLock+0x35  [c:\tests\deadlockdemo\deadlockdemo.cpp @ 90]
005aff6c 004311b1 00000000 f3d06511 00334fc8 DeadLockDemo!ThreadOne+0xa1 [c:\tests\deadlockdemo\deadlockdemo.cpp @ 182]
005affa8 00431122 00000000 005affec 7c80b50b DeadLockDemo!_callthreadstartex+0x51 [f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c @ 348]
005affb4 7c80b50b 003330a0 00334fc8 00330001 DeadLockDemo!_threadstartex+0xa2 [f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c @ 331]
005affec 00000000 00431080 003330a0 00000000 kernel32!BaseThreadStart+0x37 
   2 Id: 6fc.284 Suspend: 1 Teb: 7ffdc000 Unfrozen
ChildEBP RetAddr Args to Child              
006afc14 7c90e9c0 7c91901b 000007d8 00000000 ntdll!KiFastSystemCallRet
006afc18 7c91901b 000007d8 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc
006afca0 7c90104b 004a0620 00430b7f 004a0620 ntdll!RtlpWaitForCriticalSection+0x132
006afca8 00430b7f 004a0620 006afe6c 006afe78 ntdll!RtlEnterCriticalSection+0x46
006afd8c 00430b15 006aff60 006afe78 003332e0 DeadLockDemo!CCriticalSection::Lock+0x2f  [c:\tests\deadlockdemo\deadlockdemo.cpp @ 62]
006afe6c 00430d11 004a0620 f3e065d5 00334fc8 DeadLockDemo!CCritSecLock::CCritSecLock+0x35  [c:\tests\deadlockdemo\deadlockdemo.cpp @ 90]
006aff6c 004311b1 00000000 f3e06511 00334fc8 DeadLockDemo!ThreadTwo+0xa1 [c:\tests\deadlockdemo\deadlockdemo.cpp @ 202]
006affa8 00431122 00000000 006affec 7c80b50b DeadLockDemo!_callthreadstartex+0x51  [f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c @ 348]
006affb4 7c80b50b 003332e0 00334fc8 00330001 DeadLockDemo!_threadstartex+0xa2  [f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c @ 331]
006affec 00000000 00431080 003332e0 00000000 kernel32!BaseThreadStart+0x37

       可以看到有三个线程:主线程4fc,子线程3d8284都在调用WaitForCriticalSection等待一个线程同步对象可用。

然后,再看看锁的列表:cdb -pv -pn myapp.exe -logo out.txt -lines -c "!locks;q"

CritSec DeadLockDemo!CritSecOne+0 at 004A0620
LockCount          1
RecursionCount     1
OwningThread       3d8
EntryCount         1
ContentionCount    1
*** Locked
CritSec DeadLockDemo!CritSecTwo+0 at 004A0638
LockCount          1
RecursionCount     1
OwningThread       284
EntryCount         1
ContentionCount    1
*** Locked

       问题很清楚了,3d8284在等待调用WaitForSingleObject等待一个线程同步对象可用时,都自己锁住了一个同步对象。两者互相等待,发生死锁。

       这是一个简单的例子,在实际的应用中情况会比这复杂,但基本方法不变,具体的思路是:首先找到被锁住的线程,通过kb找到这个线程等待的同步对象,再通过!lock找到持有该同步对象的线程,顺着这个思路重复,看看最终是否线程是否能够回到最初的线程上。

       如果应用程序使用了一些更复杂的同步对象(如:Mutex),调试会更复杂,在后续的文章中再讨论。

2.2      调试CPU的高消耗

要找出消耗CPU最厉害的线程:cdb -pv -pn myapp.exe -logo out.txt -c "!runaway;q"

0:000> !runaway
 User Mode Time
 Thread       Time
   1:358       0 days 0:00:47.408
   2:150       0 days 0:00:03.495
   0:d8        0 days 0:00:00.000

其时间为该线程自创建后所消耗的总时间,因此不能说线程358当前消耗CPU最厉害,应再来一次,观察时间增量:

0:000> !runaway
 User Mode Time
 Thread       Time   
1:358       0 days 0:00:47.408
   2:150       0 days 0:00:06.859
   0:d8        0 days 0:00:00.000
如此多次,可以发现消耗CPU最厉害的是线程150

2.3      调试堆栈溢出

一般而言,堆栈溢出是由于函数的嵌套调用控制不好造成的。IDE能够很好的调试堆栈溢出。但有时,我们已经注意通过控制函数的嵌套调用来避免堆栈溢出,但堆栈溢出还是在偶尔出现,为什么呢?有某些函数在一些特定的情况下占用了过多的空间,造成了堆栈溢出。因此,我们需要知道在堆栈中函数对堆栈空间的占用情况,对此IDE没有提供简洁的方法。

操作方法:

1.        使用Debug模式编译StackOvrDemo.cpp(对这个例子,Release版本无法看到具体的函数栈)

2.        VC中使用调试状态运行

3.        一旦异常被VC捕捉到,运行命令行:cdb -pv -pn stackovfdemo.exe -logo out.txt -c "~*kf;q"

. 0 Id: 210.3a8 Suspend: 1 Teb: 7ffde000 Unfrozen
 Memory ChildEBP RetAddr 
          00033440 0041aca5 StackOvfDemo!_woutput+0x22
       44 00033484 00415eed StackOvfDemo!wprintf+0x85
       d8 0003355c 00415cc5 StackOvfDemo!ProcessStringW+0x2d
    fc878 0012fdd4 00415a44 StackOvfDemo!ProcessStrings+0xe5
      108 0012fedc 0041c043 StackOvfDemo!main+0x64
       e4 0012ffc0 7c4e87f5 StackOvfDemo!mainCRTStartup+0x183
       30 0012fff0 00000000 KERNEL32!BaseProcessStart+0x3d
   可见,ProcessStrings方法占用了大量内存,最有可能是导致堆栈溢出元凶。
   对于这个例子,你可能会疑惑ProcessStrings怎么能够占用如此多的堆栈内存,需要从ATLA2W上找原因,A2W调用了_alloca函数从栈上申请内存,这些内存只能在函数ProcessStrings退出堆栈清除时才能释放。因此,应避免在循环中调用A2W

2.4      生成转储文件(Dump

如果程序带着未知的Bug发布出去,怎么调试? 因此,在某些情况下,我们需要生成转储文件,通过转储文件来分析。我们使用可以CDB/Dr.Waton/dbghelp接口/Windgb/XP任务管理器等等方法生成转储文件。

使用CDB的方法:cdb -pv -pn myapp.exe -c ".dump /m c:\myapp.dmp;q"

选项

描述

举例

/m

缺省选项,生成标准的minidump, 转储文件通常较小,便于在网络上通过邮件或其他方式传输,当然这种文件的信息量较少,之包含:系统信息、加载的模块(DLL)信息、 进程信息和线程信息。

.dump /m c:\myapp.dmp

/ma

带有尽量多选项的minidump(包括完整的内存内容、句柄、未加载的模块,等等),文件很大,可用于本地调试。

.dump /ma c:\myapp.dmp

/mFhutwd

带有数据段、非共享的读/写内存页和其他有用的信息的minidump。包含了通过minidump能够得到的最多的信息。

.dump /mFhutwd c:\myapp.dm

如果你要为一个正在被IDE调试的进程创建转储文件,记得先使所有断点暂时失效。如果不这样做,转储文件中将带有所有断点指令(int 3)。

2.5      分析转储文件

    一般而言,我们分析转储文件希望得到下列信息::

  • 异常发生的地方 (地址、源码文件和代码行)
  • 异常发生时的调用堆栈
  • 调用堆栈上函数参数和本地变量的值

   windgbCDB都提供一个强大的命令!analyze –v来分析转储文件:cdb -z c:\myapp.dmp -logo out.txt -lines -c "!analyze -v;q"

CrashDemo.cpp演示了如何通过dbghelp接口实现自定义过滤器为异常创建转储文件。功能更完备的dbghelp接口封装在我(译者)其他的文章中将会讨论。

0:001> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************
FAULTING_IP:
CrashDemo!TestFunc+2e [c:\tests\crashdemo\crashdemo.cpp @ 124]
004309de c70000000000     mov     dword ptr [eax],0x0
EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffffff)
.exr ffffffffffffffff
ExceptionAddress: 004309de (CrashDemo!TestFunc+0x0000002e)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 00000000
Attempt to write to address 00000000 
DEFAULT_BUCKET_ID: APPLICATION_FAULT
PROCESS_NAME: CrashDemo.exe
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
WRITE_ADDRESS: 00000000
BUGCHECK_STR: ACCESS_VIOLATION
LAST_CONTROL_TRANSFER: from 0043096e to 004309de
STACK_TEXT:
006afe88 0043096e 00000000 00354130 00350001 CrashDemo!TestFunc+0x2e [c:\tests\crashdemo\crashdemo.cpp @ 124]
006aff6c 00430f31 00000000 52319518 00354130 CrashDemo!WorkerThread+0x5e  [c:\tests\crashdemo\crashdemo.cpp @ 115]
006affa8 00430ea2 00000000 006affec 7c80b50b CrashDemo!_callthreadstartex+0x51  [f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c @ 348]
006affb4 7c80b50b 00355188 00354130 00350001 CrashDemo!_threadstartex+0xa2  [f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c @ 331]
006affec 00000000 00430e00 00355188 00000000 kernel32!BaseThreadStart+0x37
FOLLOWUP_IP: 
CrashDemo!TestFunc+2e [c:\tests\crashdemo\crashdemo.cpp @ 124]
004309de c70000000000     mov     dword ptr [eax],0x0 
SYMBOL_STACK_INDEX: 0
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: CrashDemo!TestFunc+2e
MODULE_NAME: CrashDemo
IMAGE_NAME: CrashDemo.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 43dc6ee7
STACK_COMMAND: .ecxr ; kb
FAILURE_BUCKET_ID: ACCESS_VIOLATION_CrashDemo!TestFunc+2e
BUCKET_ID: ACCESS_VIOLATION_CrashDemo!TestFunc+2e
Followup: MachineOwner
注意看粗体字部分(异常发生的地址、调用堆栈信息、进一步分析异常的命令.ecxrkb)。
通过.ecxr,我们可以切换到记录了异常信息的向下文中,这样,我们就能够访问到异常发生时调用堆栈和本地变量的值。我们可使用dv命令显示函数参数和本地变量的值。
cdb -z c:\myapp.dmp -logo out.txt -lines -c "!analyze -v;.ecxr;!for_each_frame dv /t;q"
/t 选项告诉dv命令显示变量的类型信息,输入如例:
00 006afe88 0043096e CrashDemo!TestFunc+0x2e [c:\tests\crashdemo\crashdemo.cpp @ 124]
int * pParam = 0x00000000
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
01 006aff6c 00430f31 CrashDemo!WorkerThread+0x5e [c:\tests\crashdemo\crashdemo.cpp @ 115]
void * lpParam = 0x00000000
int * TempPtr = 0x00000000
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
02 006affa8 00430ea2 CrashDemo!_callthreadstartex+0x51 [f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c @ 348]
struct _tiddata * ptd = 0x00355188
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
03 006affb4 7c80b50b CrashDemo!_threadstartex+0xa2 [f:\rtm\vctools\crt_bld\self_x86\crt\src\threadex.c @ 331]
void * ptd = 0x00355188
struct _tiddata * _ptd = 0x00000000
.

2.6      虚拟内存分析

    下列命令可以显示出进程的整个虚拟内存图:cdb -pv -pn myapp.exe -logo out.txt -c "!vadump -v;q"

BaseAddress:       00040000
AllocationBase:    00040000
AllocationProtect: 00000004 PAGE_READWRITE
RegionSize:        0002e000
State:             00002000 MEM_RESERVE
Type:              00020000 MEM_PRIVATE
BaseAddress:       0006e000
AllocationBase:    00040000
AllocationProtect: 00000004 PAGE_READWRITE
RegionSize:        00001000
State:             00001000  MEM_COMMIT
Protect:           00000104 PAGE_READWRITE + PAGE_GUARD
Type:              00020000 MEM_PRIVATE
BaseAddress:       0006f000
AllocationBase:    00040000
AllocationProtect: 00000004 PAGE_READWRITE
RegionSize:        00011000
State:             00001000 MEM_COMMIT
Protect:           00000004 PAGE_READWRITE
Type:              00020000 MEM_PRIVATE

XP2003系统上,有一个更帅的命令!address,可执行下列任务:

  • 显示出进程的整个虚拟内存图,可能会比vadump更可靠
  • 显示虚拟内存的耗用情况统计
  • 判断某个地址属于哪一个虚拟内存区 (如,判断该地址是否属于栈、堆还是可执行镜像)

通过!address显示虚拟内存图:

        cdb -pv -pn myapp.exe -logo out.txt -c "!address;q"
        00040000 : 00040000 - 0002e000
                    Type     00020000 MEM_PRIVATE
                    Protect 00000000
                    State    00002000 MEM_RESERVE
                    Usage    RegionUsageStack
                    Pid.Tid 658.644
               0006e000 - 00001000
                    Type     00020000 MEM_PRIVATE
                    Protect 00000104 PAGE_READWRITE | PAGE_GUARD
                    State    00001000 MEM_COMMIT
                    Usage    RegionUsageStack
                    Pid.Tid 658.644
               0006f000 - 00011000
                    Type     00020000 MEM_PRIVATE
                    Protect 00000004 PAGE_READWRITE
                    State    00001000 MEM_COMMIT
                    Usage    RegionUsageStack
                    Pid.Tid 658.644

同时显示虚拟内存耗用情况统计:

-------------------- Usage SUMMARY --------------------------
    TotSize   Pct(Tots) Pct(Busy)   Usage
   00838000 : 0.40%       27.96%      : RegionUsageIsVAD
   7e28c000 : 98.56%      0.00%       : RegionUsageFree
   01348000 : 0.94%       65.60%      : RegionUsageImage
   00040000 : 0.01%       0.85%       : RegionUsageStack
   00001000 : 0.00%       0.01%       : RegionUsageTeb
   001a0000 : 0.08%       5.53%       : RegionUsageHeap
   00000000 : 0.00%       0.00%       : RegionUsagePageHeap
   00001000 : 0.00%       0.01%       : RegionUsagePeb
   00001000 : 0.00%       0.01%       : RegionUsageProcessParametrs
   00001000 : 0.00%       0.01%       : RegionUsageEnvironmentBlock
       Tot: 7fff0000 Busy: 01d64000 
-------------------- Type SUMMARY --------------------------
    TotSize   Pct(Tots) Usage
   7e28c000 : 98.56%     : <free>
   01348000 : 0.94%      : MEM_IMAGE
   007b6000 : 0.38%      : MEM_MAPPED
   00266000 : 0.12%      : MEM_PRIVATE 
-------------------- State SUMMARY --------------------------
    TotSize   Pct(Tots) Usage
   01647000 : 1.09%      : MEM_COMMIT
   7e28c000 : 98.56%     : MEM_FREE
   0071d000 : 0.35%      : MEM_RESERVE
Largest free region: Base 01014000 - Size 59d5c000

在有内存泄漏时,内存耗用情况统计很有用,可用来判断究竟是栈、堆还是虚拟内存在泄漏。同时最大空闲区(Largest free region)有助于我们开发要消耗大量内存的应用程序。

判断某个地址属于哪一个虚拟内存区

0:000> !address 0x000a2480;q
    000a0000 : 000a0000 - 000d7000
                    Type     00020000 MEM_PRIVATE
                    Protect 00000004 PAGE_READWRITE
                    State    00001000 MEM_COMMIT
                    Usage    RegionUsageHeap
                    Handle   000a0000

2.7      查找符号

   有时,我们需要通过名字来查找某个函数或变量的地址,CDB可帮忙。
   如,定位kernel32模块中的UnhandledExceptionFilter函数:
        0:000> x kernel32!UnhandledExceptionFilter;q
        7c862b8a kernel32!UnhandledExceptionFilter = <no type information>       
   你也可以通过通配符来查找,如:
        0:000> x myapp!*CMainFrame*
        004542f8 MyApp!CMainFrame::classCMainFrame = struct CRuntimeClass
        00401100 MyApp!CMainFrame::`scalar deleting destructor' (void)
        00401090 MyApp!CMainFrame::CMainFrame (void)     
   也可以通过地址得到名称(使用ln命令),如:
        0:000> ln 0x77d491c8;q
        (77d491c6)   USER32!GetMessageW+0x2   | (77d49216)   USER32!CharUpperBuffW
   注意:输入的地址不需要是首地址

2.8      显示数据结构

Visual Studio的观察(watch)窗口可以看到数据结构,而CDBWindbg可以看的更多(包括偏移和布局)。通过dt命令实现,如:

    cdb -pv -pn myapp.exe -logo out.txt -c "dt -b CSymbolInfoPackage;q"
0:000> dt /b CSymbolInfoPackage;q
   +0x000 si               : _SYMBOL_INFO
      +0x000 SizeOfStruct     : Uint4B
      +0x004 TypeIndex        : Uint4B
      +0x04c NameLen          : Uint4B
      +0x050 MaxNameLen       : Uint4B
      +0x054 Name             : Char
  +0x058 name             : Char

也可以显示数据结构的实例变量的布局信息,需要传入该变量的地址,如:

cdb -pv -pn myapp.exe -logo out.txt -c "dt -b CSymbolInfoPackage 0x0012f6d0;q"
0:000> dt /b CSymbolInfoPackage 0x0012f6d0;q
   +0x000 si               : _SYMBOL_INFO
      +0x000 SizeOfStruct     : 0x58
      +0x004 TypeIndex        : 2
      +0x008 Reserved         :
       [00] 0
       [01] 0
     +0x038 Address          : 0x411d30
      [00] 83 'S'
   +0x058 name             : "SymbolInfo"
    [00] 83 'S'
    [01] 121 'y'
    [02] 109 'm'
    [03] 98 'b'
    [04] 111 'o'
   [05] 108 'l'
    [06] 73 'I'
    [07] 110 'n'
    [17] 0 ''
    ...   
    [1998] -52 ''
    [1999] -52 ''
    [2000] -52 ''
 
Copyright, 251   zhangtao.it@gmail.com, itrust.cnblogs.com       

posted on 2009-04-02 21:58 iniwf 阅读(916) 评论(0)  编辑 收藏 引用 所属分类: 驱动


只有注册用户登录后才能发表评论。
【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


导航

统计

常用链接

留言簿(2)

随笔分类

随笔档案

收藏夹

IT技术

积分与排名

最新评论

阅读排行榜

评论排行榜