Click here to Skip to main content
15,889,116 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I have a A.exe(coded in C#) running on machine A, B.exe(Coded in C#) running on machine B.
A.exe needs to communicate with B.exe through TCP.
B.exe calls a C.dll(Coded in C++) through COM.
Now there a bug exists in C.dll. I do the following preparations for debugging:
(1). Open A.exe's project to debug A.exe in machine A.
(2). Open visual studio in machine B and attach B.exe process.
(3). Put C.dll and its symbol file together with B.exe, load symbols, open its source code and set breakpoints.

When debugging, I found it cann't hit the breakpoint in C.dll and tips "The breakpoint will not currently be hit. No symbols have been loaded for this document".

I am sure C.dll is matched with its pdb file.

Is there any error in my settings or this way won't work?
Thanks very much!
Posted

Here is what I usually do.
Build both B.exe and C.dll in debug mode.
Open the C.dll solution in Visual Studio and debug from this solution.
When pressing F5, it will ask for the executable.
Point it to B.exe that was build in debug mode.
 
Share this answer
 
Comments
sesha Fan 21-May-12 5:32am    
Must I have a project for C.dll? I don't have a project, it is very difficult for me to build the project for C.dll.
«_Superman_» 21-May-12 5:58am    
How do you build C.dll?
You should have a project in Visual Studio, right?
sesha Fan 21-May-12 7:47am    
By makefile. Now I have resolved this problem, I have to select "Native" and "Managed code" together when attach to B.exe because there is C++ code. Thank you very much!
Another thing you could do is write a test harness for C.dll in C++. Then you can test each behaviour (i.e. create an object, hit it with a sequence of function calls and see what the final state of the object is) and see if it does what you expect. If you make the tests mirror the behaviours the C# app expects you might be able to work out where the source of the problem is.

If it does behave as you expect then you know the bug's in the client code. If it doesn't then you know it's in the DLL. And if you haven't got the source code for the DLL you might be in trouble as you can't fix it but you might be able to work around it in your client code.
 
Share this answer
 
Comments
sesha Fan 21-May-12 7:50am    
Very useful advice! I have thought about to write a tool to test the dll, but the problem has been solved, or i will try this way.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900