I remember that this question has been many times, and many friends complained that no one can give the actual answer. Ok, today I finally wrote it, the answer is here, I hope I can help.
The main content see Microsoft's website: http://support.microsoft.com/support/kb/articles/q183/4/80.asp I have added a point here.
First introduce a little IIS related knowledge, IIS is a service in the Microsoft operating system, which is running this service with operating system level privileges, using Win2k as an example, run settings -> Control Panel -> Management Tool -> IIS Information Services To view its properties, under the main directory you can find an application to protect one, there are IIS processes, shared, independent three, the default option is a common process. The IIS process refers to the ISAPI DLL and COM components run in the process within IIS in the process of the process within the process. This result is the fastest speed, because IIS can interact directly with the DLL, component interaction, but this risk The largest, once the system is errors due to the design reasons for the component (DLL), and the joints can also cause the IIS process to crash, resulting in the IIS service abort.
When using a shared process, the system will start a process called DLLHOST.exe, hung the component (DLL) to run in this process, so that even if the system is wrong, even if the system is wrong, it can only lead to Dllhost. The process error does not destroy the core process of IIS. When such an error occurs, IIS returns the Dllhost process error message to the client with a series of means, and IIS itself continues to run normally. This way is slower than the previous one, in Windows NT, the system replaces DLLHOST in mtx.exe.
I have not used the independent process to launch the app, but I can imagine that the system will start the component in a stand-alone process, the highest reliability, but the speed is slower, because IIS is a series of Marshal and Unmarshal (column Setting and disclosure, see Pan Aimin COM principle and application books can pass the data to this independent process.
This is the reason for this, there are some old Debug methods, such as the way to debug ISAPI in the inside of the VC technology, some people have not successful, because the method given is targeting IIS process Way debugging, and IIS's default way is a common process, I have not debugged in the IIS process, I don't have to use this way.
To debug our components and ISAPI in the way of shared processes, take Win2K, VC 6 as an example, here is a detailed steps:
1. Confident, your IIS service has been launched, and your ISAPI and COM components have been compiled, in place, for example, ISAPI is in the correct virtual directory, COM components have been registered.
2. Open your Project, select Start Debug-> Attach Process under the Build menu.
3. Process lists, select SHOW System Processes (Show System Process)
4. Select the DLLHOST.EXE process (if your IIS launches the application in a shared mode), if you are in Windows NT or other versions, then select MTX.exe.
5. At this time, the system loads the resource of Dllhost. Choose Project-> Settings-> Debug, select Category -> Additional DLLS, add our write ISAPI DLL or COM components (就 xxxx.dll)
6. You can see the Output window to output a line, indicating that the resources of the component have been loaded.
7. Open the source file that you need to debug, add breakpoints in the appropriate position. If it is not possible to be interrupted at this point, it may be that your PDB file is inconsistent with the version of the DLL file, and it needs to be recompiled.
8. At this time, you open the browser, type the relevant URL, then you will wait for your program to be activated!
For a long time, I have been trying to debug the program in IIS. When the program jumped into the breakpoint in that moment, I will try it right away. I can guarantee that this method is correct. If there is still a problem, you can contact me, huh, huh, eat it.
