Detailed explanation of visual studio debugging methods

Catalog

1、 summary

2、Debug Debugging under the environment

3、Release Debugging under the environment

4、 Additional debugging

5、 summary

---

C++ A series of tutorials from getting started to mastering software exception troubleshooting （ Column list , Welcome to subscribe to , Continuous updating ...）https://blog.csdn.net/chenlycly/article/details/125529931        Use IDE Debugging code is a skill that developers must master , It is the most direct way to troubleshoot software problems , Today we will talk about using Visual Studio Several ways to debug code .

1、 summary

        When the software runs with problems , Debugging is the most direct troubleshooting method . Breakpoints can be set during debugging , It can be debugged in one step , You can view the values of related variables in the code , And then locate the problem quickly and effectively . Besides , In the case of unfamiliar code , You can also debug through breakpoints , Find out the running track and process of the code .

        Use Visual Studio It can be done to C++ code Debug debugging 、Release Debug and attach to process debug , These three types of debugging can be used in different scenarios , The following will be described one by one . The following contents are based on debugging C++ Code to expand .

2、Debug Debugging under the environment

        On a daily basis C++ When developing code , All in Debug Next on , From code development 、 From debugging to function joint debugging, it is basically in Debug Next is the finished . stay Release Problems found during program testing , If it is inevitable or easy to reproduce （ Follow the specified operation steps to reproduce ）, You can try to Debug Now it's happening again , If Debug It can be reproduced under , It can be directly in Debug Debug the code step by step .

3、Release Debugging under the environment

       Debug Version of the program and Release There are many differences in the version of the program , One of the most typical is Differences in memory management . stay Debug Next request memory , The system will allocate extra memory , Used to store some debugging information .

        Besides ,Debug The memory requested by the program will be initialized , and Release The memory requested by the program will not be initialized , Is the random value in memory when allocated to memory . These factors may lead to Debug Procedure and Relese Differences in program operation , such as Debug No problem running , and Release There is a problem running under , For example, variables are not initialized when they are defined , stay Debug The memory of the next variable will be initialized automatically , and Release The value of the next variable will be a random value , Random values can cause unforeseen errors in the program .

        For only Release Only when running under , You can try to use Visual Studio Conduct Release Debugging under the environment . It's going on Release Before debugging , You need to turn off optimization in the project attribute , As shown below ：

Because in order to improve the running speed of the program ,Release The following is optimized by default .

        When the compiler is optimizing , There may be some C++ Code optimization , For example, function calls will be replaced 、 Local variables will be optimized , If you don't turn off optimization , Debugging code will cause some code to be skipped , Some variables cannot be viewed, which is worth the problem . Of course, there are a few problems , It may be caused by optimization , After turning off optimization, the problem may disappear , Although this kind of problem is rare , But we did encounter in actual projects .

        In addition to turning off optimization , We have to build Release Compile environment , The bottom modules Release Copy the library of version , Then compile locally maintained release Library of related modules , Locally maintained modules that need to debug source code should also be release The optimization under is turned off .

4、 Additional debugging

        If we don't want to be on the top exe The module is integrated Release debugging , You can debug only one module , Only need Release Next compile a module . Or the problem lies in the underlying module , For example, modules of component groups 、 Module of protocol group 、 Module of network group 、 Modules of audio and video codec group or open source components , The developers and maintainers of these groups only need to debug the modules they are responsible for by using additional debugging .

        It only needs to be installed on the machine exe Installation package （release edition ）, They use it locally VS Compile the Release Version Library , Copy the library to exe The path where the program is located , And then exe The program starts , such exe The program uses the library just compiled . next Open the source code of the Library VS in , Click debug in the menu bar -> Attach to process , Found in the pop-up window exe process ：

Click the attach button , You can interrupt debugging .

        Someone may ask the general dll Copy library to exe In the path , Why can I debug this... When I add debugging dll The source code of the Library ？ In fact, the reason why it can be debugged , Because the debugging information generated during compilation is saved to pdb It's in the document , Compile the generated dll It will be generated by local compilation pdb The full path of the file is written to the corresponding binary file , As shown below ：（ Binary files opened in the form of text will appear garbled , Do not interfere with the view pdb route ）

For our test program TestDlg.exe, We use Notepad++ open , With .pdb Keyword search , You can search and write to TestDlg.exe In the binary file pdb The full path ： C:\Users\Administrator\Desktop\TestDlg\Release\TestDlg.pdb, As shown above .

therefore , Will be compiled dll File copy to exe In the path ,VS according to dll Written in the Library pdb The path of the file can be found pdb file , You can find debugging information , So it can be VS Debug source code .

        For additional debugging , need exe The program starts first , And then VS Attach to exe On process debugging . But if the problem arises in dll Library initialization phase , When the program starts, it will initialize the underlying dll library , If you wait for the program to start and then attach , It may be too late ,dll The code of Library initialization has been run .

        In this scenario, we have a way , Can be in exe Program main Call at the entrance of the function API function MessageBox Pop up a modal box , Block the code , Create an opportunity for additional processes . After the process is attached , Click again MessageBox OK button for , Give Way exe Keep running down , call dll Library initialization interface , In this way, you can debug dll The initialization code of the Library . It's a trick .

5、 summary

       Debug Debugging under the environment 、Release Debugging and VS Additional debugging , These three kinds of debugging need to be mastered , They are used in different scenarios . At the beginning of function development and debugging , Generally, it is mainly used Debug debugging . After the software function development is completed and enters the test , The testers are all running Release Version of the program , But we usually don't use it easily Release Debugging under the environment .

        If the program crashes abnormally while running , The exception capture module installed in our program can capture and generate exception context information dump file , We just need to get dump Files use windbg Just analyze it . If the exception capture module does not catch an exception , We need to windbg Attach to the target process to debug and run , If an abnormal crash occurs in the program ,windbg It's the first time you'll feel , So you can analyze .

        In some rare cases , Even if you get dump Documents or Windbg When dynamic debugging fails to analyze problems , The developer and maintainer of the problematic module can manually attach the code of the debugging module , See if you can find clues to the problem . If there is a logical exception in the business during the operation of the program , For example, the code that should not be entered is executed or the code that should be executed is not executed , Or there is a problem with data interaction in the code , You can also analyze and locate through a perfect logging system . The log can be printed to the console window （ such as telnet） On , You can also generate logs into files .

        If the log is written to a file , Some log control mechanisms need to be considered , The disk space occupied by log files should not be too large , Each log file cannot be too large , Otherwise, it will be very slow to open , So when writing logs to files , If the file size reaches the set upper limit , You need to cut the file （ For instance from log.txt Switch to log1.txt）. Considering that files cannot occupy too much disk space , There needs to be a mechanism of cyclic coverage .