Recently, a project was deployed on a production environment and it was discovered that some methods threw out anomalous messages
However, only abnormal error information is given, and there is no abnormal line number, only that there is a problem with the model conversion in a certain method
But let me compare them one by one, it's too annoying, why not record the wrong line number?
The log4net log configuration is as follows:
I deliberately wrote an exception message in the Home/Index method on my local computer to see if the line number would be recorded:
I found that the error log file will record the line number, which is definitely not a problem with the log4net configuration, because the configuration on both sides is the same
Could it be a problem with the compilation mode???
My local computer is in debug mode, and the dll compiled by the official server is in release mode
Then, I changed the local project to release mode, and found that it was still a record line number.
Then, Baidu, the first sentence:You need to copy the .pdb file corresponding to the dll”
Well, is this a problem? Then, I went directly to the bin directory, deleted the .pdb file corresponding to the dll, and then refreshed the website, and found the exception log as follows:
Sure enough, the abnormal line number is not recorded!!!!!
Is it really a .pdb problem!! You need to keep the .pdb file so that the line number will be recorded if it is abnormal!!!
What is a PDB file for?
PDB files: What every developer must know
What is a PDB file?
Most developers should know that PDB files are used to help with software debugging. But how exactly does he work, we may not be familiar with. This article describes the storage and contents of PDB files. It also describes how the debugger finds the PDB file corresponding to binay and how the debugger finds the source code file corresponding to binay. This article is for all Native and Managed developers.
Before we begin, let's define two terms: private build, which is used to denote a build generated on the developer's own machine; public build, which means a build generated on a public build machine. private build is relatively simple, because PDB and binay are in the same place, and usually the problems we have are about public build.
The most important thing that all developers need to know is that "PDB files are just as important as source code", without which you can't even debug. For public build, the symbol server needs to store all the PDBs, and then when the user reports an error, the debugger can automatically find the corresponding PDB file in binay, and both Visual Studio and Windbg know how to access the symbol server. Before storing PDB and binay to the symbol server, you also need to source index the PDB run, which is to associate PDB and source.
The next part assumes that the Symbol Server and Source Server Indexing are already set up. TFS2010 can be done as simply as source indexing and symbol server copying for a new build.
2. The content of the PDB file
Officially starting the content of PDB, PDB is not a publicly available file format, but Microsoft provides an API to help get data from PDB.
The Native C++ PDB contains the following information:
* public, private and static function addresses;
* The name and address of the global variable;
* Parameter and local variable names and offsets on the stack;
* typedefinitions of class, structure and data;
* Frame Pointer Omission data for traversing the native stack on x86;
* The name and number of lines in the source code file;
The .NET PDB contains only 2 parts of information:
* Source code file name and number of lines;
* and the name of the local variable;
* All other data is already included in the . NET Metadata;
|
Posted on 8/3/2017 2:13:01 PM
|
|
|
|
