DEBUGGING SHELL EXTENSIONS USING DELPHI
Nowadays the integrated programming environments - Borland Delphi and Borland C++ Builder represent rather convenient means for developing Windows Shell extensions (further on: Shell extensions).
In contrast to the Microsoft development environment, where all of the Shell extension code is embedded in the template, generated with the help of «Shell Extension Wizard», Delphi and C++ Builder provides you with the opportunity to use similar Template Wizards, it also provides a faster and simple visual approach for Shell extensions developing, for example the «Shell+» components package (www.shellplus.com).
In any case the important question is the debugging of your Shell extensions. This article was written to assist the programmers, who use Borland Delphi (C++ Builder) for developing Shell extensions. It will be equally useful to both those who use the visual approach, and those, who write Shell extensions "from scratch".
As for any other DLL debugging you should specify the Host Application for your Shell extension. Your Shell extension will be loaded into the address space of this application. In our case such an application is represented by Windows Explorer. Go to the menu Run | Parameters..., press the Browse button and choose the Explorer.exe file from the Windows directory. Do not hasten to start debugging though, there are a lot of significant nuances ahead.
You should include all the necessary debugging information into your project. For this purpose open the window «Project Options» (using the menu Project | Options...), proceed to the «Linker» tab and in the group «Exe and Dll Options» check the «Include remote debug symbols» item. It should activate generation the special data for remote debugging, which are also necessary for debugging COM-applications. When you are done with the debugging of your Shell extension do not forget to switch this option off, as it considerably increases the size of the module and creates an even greater-sized file with the extension *.rsm, which stores all the symbols for the remote debugging. For the convenience of debugging it’s also recommended to check «Use debug DCUs» in the «Compiler» tab of the «Project Options» dialogue. It will allow you to keep track of the internal work of the modules, which were not included into the list of your project modules.
You should also keep in mind the availability of the source code of your Shell extension for the Delphi debugger. They should be located in the current Delphi directory or the path to them should be registered in the Project | Options | Directories/Conditionals, item - «Debug Source Path».
On completion of all adjustments to the project’s properties you should rebuild the entire project (through the menu item Project | Build...).
If you use Windows XP, you should have difficulties with debugging DLL-libraries. They are as follows - the Delphi debugger does not load the debugging information symbols from the library.
This mistake has already been corrected for Delphi 7, but if you work with the earlier versions, you may find the following advice useful: do all the preparations for debugging as described above, then start debugging. Once the main application has been started, switch to Delphi and press the Ctrl + Alt + M combination of keys. In the opened list of the loaded modules find your module, right-click on it and choose Reload Symbol Table. Enter the complete path to your DLL in the window, which will appear, and press OK. The remote debugging symbols table should be reloaded and you will get the opportunity to set up the breakpoints and track your Shell extension work.
The carrier of the Shell functionality is the Windows Explorer application. On the computer screen you can see such objects as Desktop, Taskbar, and contents of the folders. All these objects are supported by the Windows Explorer application, and you can see his process in the Task Manager.
The bound to it process is referred to as Explorer.exe. You can also see there, that sometimes several copies of this process are running. Do not be surprised –– it depends on the Windows properties, as will be shown later.
Windows Shell automatically unloads a dynamic library when its internal counter is equal to zero, but it occurs only at the expiration of a certain period of time. It is done to accelerate the work of the environment, but it is not always convenient while writing or debugging Shell extensions within the limits of one operational system - at compilation of an already registered Shell extension its file may appear blocked for writing. For the operational systems of versions earlier than Windows 2000 you can reduce this period by feeding the following information into the register:
| HKLM Software Microsoft Windows CurrentVersion Explorer AlwaysUnloadDll |
When you are done with the debugging of your Shell extension do not forget to switch this option off, as it has a bad effect on Windows productivity.
In any operational system it is possible to apply the following method to start Windows Shell under debugging:
Debugging Shell extensions under Windows NT/2000/XP you can setup the start of several copies of Windows Explorer (separate copies for Task Bar, for each window with the contents of folders or disks, etc.). As a result you will be able to debug your Shell extensions without unloading Task Bar and Desktop, which is much more convenient. To setup this opportunity you should add the following information to the register:
| HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Explorer\ DesktopProcess(REG_DWORD) = 1 |
To make the feature take effect you should Log off and then Log on. When you are done with the debugging of your Shell extension do not forget to switch this option off, as it slows down Windows considerably.
Shell Extensions Debugging
After all the preparations have been done you can press Run (F9) and start debugging your Shell extension. Set up the interruption points in the appropriate places, use the buttons "Program Pause" and "Program Reset" if necessary. There are no other differences between debugging Shell extensions and debugging regular Delphi applications. Also, do not be surprised, if breaking the project debugging through «Program Reset» will cause an automatic Windows Explorer loading. It is the standard reaction of Windows to errors while quitting an Explorer process. To end up the debugging process successfully you can take advantage of the way described above (through Start | End of work).
Windows Explorer is a multi-thread application. For every Shell extension in use it creates a separate thread, in which it works with it further. Therefore do not be surprised, if during the step-by-step debugging you will suddenly be thrown to some other code area, where you have debugged recently, and then returned to the initial spot. You can keep track of your travels through the threads in the window Thread status, which can be opened through the menu View | Debug Windows | Threads.
As you can see, Shell extension debugging is not complicated. We wish you good luck in developing useful and successful Shell extensions.