Use COM symbol Engine auxiliary debugging
Release Date: 4/1/2004
| Update Date: 4/1/2004
John Robbins
Download this article: BugsLayer0800.exe (35KB)
In the magazine in the issue of April 2000, I talked about a COM package I have wanted to build a DBGHELP.DLL symbol engine. I also acknowledged some problems at the time, because I know the database's understanding is not enough to develop OLE DB provider packaging, and these database knowledge is this. Interestingly, many people commented that I am not afraid to admit that my ignorance is too powerful. After some discussion with various types of developers, I was surprised to understand that everyone can open up their own weaknesses. I found that the developers think that they don't know what they have a weak performance. This may become a problem with the team development.
What truly surprised me is that many developers intentionally do not arrange the learning time they need to improve when arranging development time. Because my major is to find a program error, the developer does not arrange this fact for learning, in my opinion, it is obviously a big warning flag. If the developer just wants to learn the knowledge you need to develop, there will be two huge vulnerabilities, which will slip excessively wrong. The first vulnerability is because it works in an unknown field, and the quality of the design will be a lot. The second vulnerability is, although it can also develop a similar program, but because you have to keep more and more the latest patchs can make the entire program run normally, you will eventually find yourself into one "Functional spreading quagmire". As long as there is a little industry experience, you will know that the function spread is the biggest cause of the wrong. These two erroneous vulnerabilities, it will lead people to start their own progress!
Knowing it is known, I don't know, it is absolutely correct. Today's computer program design industry and the pharmaceutical industry are somewhat similar, because each industry must become an expert to survive. The technology is so deep and complex, so that it is necessary to express satisfactabily and must focus on several areas regardless of other areas. The problem is that not all programmers can keep up with the times. A healthy team should have a good understanding of everyone's condition, so that training fees can be used correctly to improve team strength. In addition, during the project, it can make the design, which makes the design excellent, and the function spreads less, ultimately close to the scheduled release date.
Ok, thank you for giving me an opportunity to explain your own development philosophy. Here I want to go to the implementation of the COM symbol engine. When I started to discuss these related questions, I have asked, whether someone can provide some ideas, talk about how to settle up to solve them. The biggest benefit of writing this column is that I can virtually meet with developers around the world, they have extremely rich experiences, and there are some truly and all ideas to solve various development problems. Therefore, the COM symbol engine uses some interesting techniques. When you must pack existing interfaces with a new COM package, these techniques can be considered. Before you go to the implementation details, I have to make some problems that care about when I realize the COM symbol engine.
Problem
At first glance, most of the code is trivial in the COM packages above the DBGHELP.DLL symbol engine. Many functions of many functions are just directly from the API function to a method. Of course, the first big disadvantage of the DBGHELP.DLL symbol engine is that it is all based on an ANSI string, so the COM package must be converted in large amounts of ANSI to BSTR. The real big problem in the DBGHELP.DLL symbol engine is related to the symbols and module enumeration because they use the callback function. Previously, Windows-based development is usually done in C language, and the callback function of enumeration is an excellent technology that can be adopted when the implementation of a particular data structure is hidden. The enumeration function may not disclose the data structure, but a function pointer needs to be called internally in the data structure. The disadvantage of the callback mode is that there is no function pointer in COM. Because SymeNumerateModules and SyMenumerateSymbol are implemented with a callback function, a solution must be given.
One of the design objectives of COM packaging is to comply with the standard IENUM * interface. Although non-standard enumeration programs work (and no one should complain about this), but I want the entire interface to work like other interfaces. I thought two possible solutions when considering the method of complying with the Ienum * interface, I thought two possible solutions. The first is to save the previous enumerated symbol, when the next symbol is required, call the C interface to continue enumeration to the next one. Although this is able to run (because most symbolic tables have thousands of items), they are certainly very slow. Another solution is to consider yourself to achieve enumeration, and store results for later use. That means actually to copy the entire symbolic data in memory, so it will make the memory demand for COM packs more than double.
As I said in the April 2000 column, the two solutions did not seem too attractive, so I took the old way of column writers: Help in excellent readers. I will introduce the object model and some relatively easy implementation, then discuss several excellent solutions proposed by smart readers.
Back to top
Use and easy implementation
The use of the COM symbol engine should be very simple. The name of the method remains the same as the name of the C language DBGHELP.DLL symbol engine. In this way, those who have experience in existing symbolic engines are easier. And those who have no symbolic engine, MSDN Library have all the documents to use the required documents. For Visual Basic-based client samples using the COMSymbolengine object, see the VBTest application included in this month. Figure 1 shows a simple object model for a COMSYMBOLENGINE object.
Figure 1 COMSYMBOLENGINE
Because several structures in the DBGHELP.DLL symbol engine are scalable (such as ImageHLP_SYMBOL), we use old-to-trustful alternate technology-activity template library (ATL). Most methods in the main interface ISYMBOLENGINE are simple packages for actual functions. Some examples can be seen in Figure 2, such as Isymbolengine :: Syminitialize and Isymbolengine :: SymloadModule. It can be seen that most of the work is related to the error check and string conversion.
Because the DBGHELP.DLL symbol engine relies on several structures to return data, these structures can be automatically converted into their respective interfaces. For example, the ISYMBOLINFO interface is just another name of the ImageHLP_SYMBOL structure. ImageHLP_LINE structure maps the iLineInfo interface, and the imagehlp_module structure maps the ImoxleInfo interface. When you discuss the enumeration, the ImoduleInfo interface is not a simple structure mapping. The main interface isymbolengine also inspiring some events. The DBGHELP.DLL symbol engine provides a mechanism that receives notifications when a symbol engine information is sent via the SymRegisterCallback notification. Because the concept of notification is mapped directly to the COM event, its implementation is not too exciting. When using the COMSymbolengine object, you may need to consider handling these events to see if the symbol engine has any questions.
Back to top
Handling enumeration
Now let us go to a fun part: modules and symbol enumerations. If you have seen the COMSYMBOLEGINE object, you can see that I actually achieve two § different modules and symbol enumeration techniques. I do this, I want to explain it: Two techniques are completely effective solutions for solving problems raised in a question section.
The ABU WawDa and Chris Sells have independently proposed the first technique. For me strictly complied with the limit of Ienum *, they think that I have a little too much. The solution they propose is to let SymenumerateRateModules and SymeNumerateSymbols's callback functions excited to each enumeration. Complete this task using the connection point is very fast, very easy to implement, and it is also very intuitive for all people who use the COMSYMBOLENGINE object.
A small problem for enumerating connection points for enumeration is required to provide developers to provide stop enumeration. You can stop the enumeration from the respective event handler to call the StopModuleEnumeration and the StopSymboleNumerative method. The ISYMBOLENGINE :: SymenumerateSymbols and ISYMBOLENE :: StopsymboleNumerative method and supportive COMSYMBOLENEENEENUMSYMS callback functions are shown in Figure 3.
The second method of processing enumeration comes from Chris Treichel's talented advice. When I received a chris email, I couldn't help but be my heart. I have been looking for a way to control callbacks, and the fiber is the perfect solution to this. Microsoft earliest introduces the fiber in the operating system, to help developers transplant from UNIX to Windows. It seems that many UNIX products have realized their own thread processing mechanism. Because the fiber can be used to accurately control the execution, it is a great solution for my COMSYMBOLENGINE object puzzle.
In order to enumerate the symbol and module enumeration code running in the fiber, I will put them all in a file called FiberCode.h and FiberCode.cpp. Figure 4 shows the symbol enumeration part of the code. The first called function is Initializesymbolenumeration, which creates a small data structure with data passed to the fiber function. Note that the code did not show that I have converted the controlled primary thread into a fiber. After filling the shared data structure, I created a symbol enumeration cutter, which will not be executed after calling SwitchTofiber.
The stop symbol enumeration is very simple: just call the endsymbolenumerative. The only thing you need to do is to delete symbol enumerations. Escrew the symbols, this can be seen in GetNextSymboldata. In this function, the first step is to switch to the enumeration fiber and let it perform an enumeration. When the enumeration is performed, the result is copied from the shared data structure. Finally, if the enumeration is indeed, the enumeration fiber is terminated. The two functions shown in Figure 4 are executed in the context of the symbol enumeration. SymboleNumerationFiber is the actual fiber function itself, which will call the SymeNumeRASYMBOLS function. Because you can't let the fiber you end, the last operation it execute is to switch back to the main fiber after indicating the end of the enumeration. The implementation of the symbol enumeration callback is almost equally easy. After each iteration in Symsymenum, the function switches the context to the main fiber, so that the controlled symbol enumeration is realized.
After a simple fiber treatment, you can fully support modules and symbols with the interfaces and standard COM collection classes derived by Ienumvariant. Because interesting places here are the core fiber, you must view the source code to get a complete implementation. You can also check the Visual Basic sample vbtest to make sure all enumerations are fully compliant with Item selection in Visual Basic and for ... Each ... next semantics.
To learn more about the fiber, please refer to MSJ November 1996 Win32 Q A column of Jeffrey Richter. The last point I would like to mention is a smart ATL macro that is especially useful when debugging. COM_INTERFACE_ENTRY_BREAK Macro triggers a breakpoint when querying a specific interface. Simply put the COM_ITERFACE_ENTRY_BREAK macro in the COM Map macro in the interface to be stopped. I found that set breakpoints from the ATL source code from the ATL source code, it is better to use COM_ITERFACE_ENTRY_BREAK.
Back to top
Conclusion
I know some readers wait for the comsymbolengine object for a long time, because this commitment is almost 18 months ago. For readers who are in a new and improved COM world transition from the old system, you may want to know the riding process of converting C interface. I hope that these efforts can save you some time.
Back to top
skill
In the hot summer, when you are hot, if you think of debugging skills while sitting on a break, please remember to send me by email, my email address is: john@wintellect.com.
Skills 35slorakia's Joseph Sebestyen wrote: In MSJ June 1, 1998, you demonstrate how to set an ESP register in the MEMORY window to find function parameters in the stack. In order to find parameters in the stack of a function's headline instruction, I used (INT *) @ ESP) in the Watch window, 10 (where 10 is the number I want to see). The document has not been recorded, # format setting (this is my other skills ") will automatically expand into an array view. When the standard frame function is single step (those using the PUSH EBP or MOV EBP, ESP as a function of the ProLog sequence), the WATCH window expression can be changed to ((int *) @ ESP 1), 10.
Skills 36 Jonathan M. Gilligan Dr. Wen: I have used many such classes in my work that contains pointers (such as trees and related data structures) to other classes or to the same class other objects. Sometimes in debug, it is determined that it is observing which example may be very difficult, especially when this example is the function parameter to be transmitted or aliased. I have added a "serial number" member to all classes to assist in identifying something similar.
// Class Declaration
Class foo
{
Private:
Static unsigned s_ulastserialno;
UNSIGNED M_USERIALNO;
...
}
// in the implementation
Unsigned foo :: s_ulastserialno = 0;
Foo :: foo (): m_userialno ( S_ulastSerNo)
{
// Initialization
}
Now if there is an error related to a particular object, I can use Trace output or conditional breakpoints to focus on all things that will affect this particular object.
