Table of contents
1. Why should I learn to use common analysis tools of C++ software?
2. What are the commonly used analysis tools for C++? What specific problems can be addressed?
2.1, window information viewing tool SPY++
2.2. Module dependency viewing tool Dependency Walker
2.3, GDI object viewer GDIView
2.4. Process information viewing tool Process Explorer
2.5, process activity monitoring tool Process Monitor
2.6. Function call monitoring tool API Monitor
VC++ common function development summary (column article list, welcome to subscribe, continuous update...) 
https://blog.csdn.net/chenlycly/article/details/124272585 C++ software exception troubleshooting series tutorial from entry to mastery (column article list , welcome to subscribe, keep updating...) https://blog.csdn.net/chenlycly/article/details/125529931 C++ software analysis tool case collection (column article is being updated...) https://blog.csdn .net/chenlycly/article/details/131405795Through online communication and offline daily contact with colleagues from multiple departments, I found that many C++ developers have relatively simple means of analyzing problems when problems or exceptions occur in C++ software. The efficiency is relatively low, and sometimes it even affects the work and project progress. It is necessary to master the use of some common C++ software analysis tools. Today we will talk in detail about why we need to learn C++ common software analysis tools, and what are the benefits of mastering the use of these tools.
1. Why should I learn to use common analysis tools of C++ software?
After the project goes online, in order to effectively deal with various problems encountered by customers in the process of using the software, we need to master a variety of software debugging methods and methods. We must master the skills of troubleshooting software abnormal problems and only rely on a single method Or the means are not enough.
C++ software debugging technology includes many aspects, and mastering the use of common analysis tools for C++ software is also one of the important contents. Mastering the use of common C++ software analysis tools can assist in the analysis of various C++ software problems, and can effectively improve the efficiency of troubleshooting. It is not enough to rely solely on IDE development tools to debug code. For problems that are difficult to reproduce or only occur in the customer's environment, or only on the customer's individual computer, a variety of technical means must be used to troubleshoot.
Master the use of common tools, be able to quickly analyze and locate problems, and solve problems that ordinary people cannot handle. This is not only a manifestation of personal skills, but also a reflection of the company's value.
2. What are the commonly used analysis tools for C++? What specific problems can be addressed?
In the process of C++ software development and maintenance, some efficient software analysis tools will be used to assist in the analysis and troubleshooting of various problems encountered in software operation. Daily analysis tools include SPY++, Dependency Walker, clipboard viewing tool Clipbrd, GDI object viewing tool GDIView, Process Explorer, Process Monitor, API Monitor, debugger Windbg, interactive disassembly tool IDA, packet capture tool Wireshark, etc.
2.1, window information viewing tool SPY++
SPY++ is a tool that comes with Microsoft Visual Studio to view window properties, window messages, processes and threads. It is often used to deal with UI window affairs in daily work.
Use SPY++ to view the window style (such as WS_POPUP, WS_CHILD, WS_EX_TOOLWINDOW, etc.), window coordinates and dimensions, window title and window class name, and use this information to assist in troubleshooting UI window problems.
By looking at the class name of the window, we can probably guess which UI framework is used to implement the corresponding UI interface of the software. Commonly used UI interface frameworks include MFC, duilib, QT and Chrome browser UI components.
For an example of using SPY++ to analyze problems, please refer to the previously written article:
Use SPY++ to view window information to analyze C++ client UI software problems https://blog.csdn.net/chenlycly/article/details/130280965
2.2. Module dependency viewing tool Dependency Walker
Use Dependency Walker to view which dll libraries the exe main program depends on, and the dependencies between dll libraries. It is mainly used to troubleshoot the failure of program startup or the failure of dynamically loaded dll libraries to load due to missing libraries or interfaces in libraries. question.
When the exe program starts, the dll library they depend on will be loaded into the process space first, then the exe program will be loaded, and then enter the main function to run. If the dependent dll library cannot be found in the currently running system, or the calling interface cannot be found in the dependent dll library, the program startup process will be terminated and the program startup will fail. When dynamically loading the dll library, the process of loading the exe program is similar.
For an example of using Dependency Walker to troubleshoot problems, please refer to the previous article:
Use Process Explorer and Dependency Walker to troubleshoot the failure of dynamic loading of dll libraries in C++ programs https://blog.csdn.net/chenlycly/article/details/130198751
2.3, GDI object viewer GDIView
Use GDIView to view the number of various GDI objects occupied by the process and the total GDI occupied by the process. It is mainly used to troubleshoot GDI object leakage in UI interface programming. When a GDI object leak occurs, first use this tool to determine which GDI object is leaking, and then look at the code for analysis.
In the Windows system, the total number of GDI objects in a process has an upper limit. The default is 10,000. When the upper limit is approached or reached, the GDI drawing function will fail to execute, and the window will display abnormally, followed by a crash.
For examples of using GDIView to troubleshoot GDI leaks, please refer to the previously written article:
Use GDIView tools to troubleshoot GDI object leaks https://blog.csdn.net/chenlycly/article/details/125399896
2.4. Process information viewing tool Process Explorer
The Process Explorer tool is similar to the Windows task manager, but its function is much more powerful than the Windows task manager. The main functions of Process Explorer are as follows:
1) Check the command line startup parameters passed in when the process starts. For example, the chrome browser will start multiple processes, and use the command line parameters to distinguish the purpose of each process.
2) View which dll libraries are loaded by the process, and the full paths of these libraries. Use this type of information to check which dll files are loaded by the exe program and the path of the loaded dll library, and check whether the dynamically loaded dll library is loaded. This function point is more commonly used, such as this case:3) View disk and network usage statistics for processes.
4) View the information of each thread of the process, you can see the CPU usage ratio of each thread and the function call stack of the thread. You can use this to troubleshoot the high CPU usage of the program. This function point is also commonly used, such as this case:
5) Check the GPU usage of the process to determine whether the program uses GPU hardware codec.
6) Check the virtual memory usage of the process. Windows Task Manager cannot see the total virtual memory usage of the process (only physical memory related information can be seen). You can use this tool to check it, which can assist in troubleshooting memory leaks.
7) View the handle information occupied by the process, such as file handle, thread handle, registry handle, etc. There is also an upper limit on the number of handles of a process. If it reaches or exceeds the upper limit of the total handles of a process, it will cause problems in the creation of subsequent handles.
2.5, process activity monitoring tool Process Monitor
The use of Process Monitor is mainly used to monitor the registry activity and file activity of the target program. By monitoring the process registry activity, you can figure out which registry entries are read and written when performing an operation, such as the following cases:
Use Process Monitor to detect the registry key of the high DPI scaling setting of the Windows system https://blog.csdn.net/chenlycly/article/details/130586460 You can find out which module generated a certain file by monitoring the process file activity , such as this case:
2.6. Function call monitoring tool API Monitor
Using API Monitor to monitor the function calls of the program to the system library or third-party library has two main purposes. One is used to imitate the function implementation of other software, monitor which system API interfaces are called by other software (generally software from some mainstream manufacturers) when implementing a certain function, and which parameters are passed when calling. The second is to monitor which module of the program calls a certain API function of the system. When the function call record is monitored, you can view the parameter values passed when the function is called, and you can also see the corresponding function call stack. Through the function call stack, you can see which module is called.
We have also used this tool many times in the project to detect the function calls of mainstream software when implementing a certain function. For example, we use IShellLink and IPersistFile two COM interface classes to create shortcuts in the installation package program, but there are always problems with the shortcuts in the 64-bit operating system, so we try to use API Monitor to monitor the installation package of a mainstream software in Goose Factory During the installation process, see which COM interfaces are called by mainstream software. On the API Filter page on the left side of the API Monitor, we checked all the functions of the entire IShellLink COM interface class (including the narrow-byte version of IShellLinkA and the wide-byte version of IShellLinkW), and then enabled the monitoring of mainstream software. Sure enough, I saw several interfaces that were not called in our program:
So imitating the calls of these COM interfaces and the parameters passed in when calling, solved the above problems.
Another example is that the security department found an unknown port number of 2620 during the port security monitoring of our software. It is not known which module occupies this port, and the developer needs to clarify it here. Considering that the binding port will definitely call the socket socket function bind, this function is a function of the system library, you can monitor the call of the function by the program to see which module is bound. First search for the bind function on the API Filter page, and check it, and then find the target process in the process list to start monitoring. Because there are multiple places that will call the bind interface, multiple records will be monitored. We need to see which record operates with a port number of 2620, and then check the function call stack corresponding to the record, which can be determined through the function call stack. Which dll library operates the port of 2620. I wrote a test program by hand to demonstrate the use of this tool. The relevant monitoring results are as follows:
However, API Monitor does not support loading pdb symbol files, and the specific function name that calls the bind interface may not be visible in the function call stack. This is not a big problem, as long as we know the specific module name and search in the source code of the module, we will know where to call the bind function. Links to articles related to this case are:
Use API Monitor to cleverly detect the module listening to port 2620 in the C++ program https://blog.csdn.net/chenlycly/article/details/130235829 For another example, when we realize the function of prohibiting the screen saver after entering the meeting, it is estimated that the system API is called The function SystemParametersInfo, and it is not sure what parameters are passed in. So use API Monitor to monitor the mainstream conference software to see if the mainstream conference software calls this interface when joining a conference, and what parameters are passed in. The monitored results are as follows:
The interface was indeed called, and the incoming parameters were seen, so the function was implemented referring to these parameter values. Links to relevant case articles are as follows:
2.7, debugger Windbg
Windbg is a powerful debugger tool provided by Microsoft, and it is the most commonly used and important tool for us to analyze C++ software exceptions. When there is a dump file, use Windbg to statically analyze the dump file; when there is no dump file, you can use Windbg to dynamically debug.
We have talked about the Windbg tool in detail many times and written many articles, so we won't repeat it here. You can check out several articles about Windbg written before:
Introduction to Windbg debugging tools https://blog.csdn.net/chenlycly/article/details/125505992 Summary of Windbg debugging commands https://blog.csdn.net/chenlycly/article/details/51711212 Using Windbg to statically analyze dump files in general Detailed steps and key points https://blog.csdn.net/chenlycly/article/details/130873143 General steps and detailed points of using Windbg to dynamically debug the target process https://blog.csdn.net/chenlycly/article/details/131029795
2.8, disassembly tool IDA
Sometimes we need to check the context of the assembly code to help troubleshoot problems. We mainly use the IDA tool to open the binary file to view the assembly code in the binary file. In fact, the binary file stores the binary machine code, the binary machine code and the assembly code are equivalent, and the assembly code is the mnemonic of the binary machine code.
The IDA tool is to translate the binary machine code of the binary file into assembly code. This process is also called disassembly. There is also a concept of reverse engineering, which is to reversely deduce the source code implementation of the program through assembly code.
For how to use IDA, you can check out my previous articles:
Detailed explanation of the use of IDA disassembly tools https://blog.csdn.net/chenlycly/article/details/120635120 Use IDA to view the assembly code context to assist in troubleshooting C++ software exceptions https://blog.csdn.net/chenlycly/article/ details/128942626
3. Summary
The functions and uses of some commonly used software analysis tools are described in detail above, and relevant problem example analysis articles are given, which have certain practical reference value. Master these commonly used software analysis tools, when you encounter problems, you can have more means and ideas, and you can use a variety of methods to locate problems quickly and efficiently.
Do more, practice more! Growing up in problems, accumulating experience in problems, solving more problems, seeing more problem scenarios, enriching actual combat experience, and broadening the thinking of troubleshooting problems.
Interest is the greatest teacher, not so much interest as curiosity and thirst for knowledge. Curiosity (knowledge) is very important, and sometimes it is an invisible source of motivation. Whether it is learning technology or the use of learning tools, we all need to have a certain degree of curiosity. For example, how do others efficiently use these tools to troubleshoot problems (pay attention to the main points and details), and how is a certain function code implemented internally!
It may not be difficult to do one thing, but the difficulty lies in persistence; it may not be difficult to persist for a while, but the difficulty is to persist to the end! The learning of a technology requires continuous efforts and unremitting persistence. We need to do it manually, apply what we have learned to work practice, continue to practice in learning, and continue to learn in practice! In our long career, it is through many small events from quantitative change to qualitative change to achieve technological improvement.