Jump to content
  • Advertisement
Sign in to follow this  
OrenGL

[.net] Debuging in VS .NET weird problem

This topic is 4252 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm having a weird problem with debugging. My application is a C# GUI and MC++ wrapper for an unmanaged C++ core. When the C# part calls the render function the MC++ is called and then the unmanaged part is called. I can debug line by line with no problem until I reach an unmanaged function containing the line: D3DXMATRIXA16 mWorldViewProjection = g_matWorld * g_matView * g_matProj; Then the debugger just goes strait into the functions within that function (like useing F11) skipping the function body. If I put a line like: int stop_here = 0; with a break point on it in the function the debugger just skips it (and has a '?' on the break point). If I remove every thing from the function and only leave the line: int stop_here = 0; it has no problem stopping there. Anyone every have this problem before? Could it be something with compilation settings? Thanks for any leads :)

Share this post


Link to post
Share on other sites
Advertisement
No one?

How would you try tackling this problem if you had it? I've got no Idea what to try...

The whole thing works ok, it just means I need to develop in one project and then move it to the next. I think I'll just try posting in a few more .NET forums if I get an ansewer I'll let you all know.

Share this post


Link to post
Share on other sites
There are a couple of things I'd try, but the very first would be to make absolutely sure that my MC++ wrapper and unmanaged C++ component was copied to the directory for access from my C# code. There can be some odd behaviour with setting breakpoints if the environment's debug symbols don't match the binary in place, and I can't imagine that going from Managed to Unmanaged would do anything but exacerbate the issue. The ? beside your bp makes me especially suspicious that this could be the case - if you change code in a running C# app and try to set a bp in that section of code you get the same behaviour.

The second thing I'd try is hooking cordbg up to the app and seeing if the results vary. I don't know how well cordbg handles unmanaged code, however.

Beyond those two, I'd be starting to seriously consider sticking to a single language for development. Unless learning about the topic of mixed-paradigm code is one of your specific goals with the project (as opposed to writing a functioning product), you're far less likely to have issues with both feet firmly planted in the same world.

Share this post


Link to post
Share on other sites
I have run into this problem as well and it is very infuriating. I do not have a lot of time right now for a thorough discussion but basically, what I discovered was that .NET for some reason thought that the code path was unreachable. I knew that it wasn’t, but I have a feeling that because the code was in a DLL, there was some sort of confusion.

VC6 used to have a simple way of telling an executable in test that there are additional DLLs required for the program and where to find them. .NET changed that, and I forget how I solved that when I ran into it. Regardless, I can offer only two real quick suggestions:

1st - if it is in a dll (and you are just coping the dll into the executable's directory for testing), delete the dll and then go into a debug session. It will obviously fail, but that is not the point. Then, either re-copy the dll back or rebuild the dll and copy it back. The best way to do this is to configure all the dependencies but I have a 1500 meeting and don't have time to look it up.

2nd - If it's not in a dll or lib I would try smoking the resource files (not the solution or project files) and start VC again. This was a common fix in VC6 to get around the frequent problems with UI issues and may work here.


Hopefully that helps or at least points you in a direction... (of course, you may also want to ensure that the codepath does get called...).


#dth-0

Share this post


Link to post
Share on other sites
First thanks for the replies :)

Quote:
Original post by liquiddark
first would be to make absolutely sure that my MC++ wrapper and unmanaged C++ component was copied to the directory for access from my C# code.


Since both projects are .NET projects I just added a reference within the C# project to the wrapper project. I'm sure they are both using the same dll since I can rebuild and look at the file time stamp and both the dll in the wrapper project and the one in the C# project have the same time.

Quote:
Original post by liquiddark
The second thing I'd try is hooking cordbg up to the app and seeing if the results vary


From MSDN:
"Currently, you can only use Cordbg.exe to debug managed code; there is no support for debugging unmanaged code."
You can read it here. if you'd like. Since my problem is in the unmanaged part it's not going to help.

Quote:
Original post by liquiddark
I'd be starting to seriously consider sticking to a single language for development. Unless learning about the topic of mixed-paradigm code is one of your specific goals with the project (as opposed to writing a functioning product), you're far less likely to have issues with both feet firmly planted in the same world.


Well my whole point is making an editor on build C++ code using C# instead of MFC. It works, even works pretty fast too. Just this weird debug thing. Oh yeah and some other weird stuff too… but I found out how to fix those ;)


Quote:
Original post by xiuhcoatl
1st - if it is in a dll (and you are just coping the dll into the executable's directory for testing), delete the dll and then go into a debug session. It will obviously fail.


No it doesn't. I think what is happening is that VS checks if the wrapper project is built if it is it just copies the dll to the needed location in the C# project. So if I delete the dll in the C# debug dir it just gets copied to there, and if I delete the dll in the wrapper project it requires that I rebuild the wrapper project. In both cases I still keep getting the same problem

Quote:
Original post by xiuhcoatl
2nd - If it's not in a dll or lib I would try smoking the resource files (not the solution or project files) and start VC again. This was a common fix in VC6 to get around the frequent problems with UI issues and may work here.


I tried doing that (deleting .rc files) but it didn't help. I don't have any UI in the wrapper project its only the engine. The GUI is in the C# part.


Again thanks for the replies. Just one more thing I noticed is that if I go over the (?) Breakpoint I get the following Tool tip:
"The Breakpoint will not currently be hit. No executable code is associated with this line."

Share this post


Link to post
Share on other sites
Quote:
Original post by OrenGL
Again thanks for the replies. Just one more thing I noticed is that if I go over the (?) Breakpoint I get the following Tool tip:
"The Breakpoint will not currently be hit. No executable code is associated with this line."

Are you sure this file is getting built? If it's included in the project as a non-source file it won't be. An easy way to check this is simply to drop the file and re-add it to the project, then try the exercise. A bit annoying, maybe, but only a moment's effort. There should also be .obj files built for the source file.

Share this post


Link to post
Share on other sites
Quote:
Original post by liquiddark
Are you sure this file is getting built? If it's included in the project as a non-source file it won't be. An easy way to check this is simply to drop the file and re-add it to the project, then try the exercise. A bit annoying, maybe, but only a moment's effort. There should also be .obj files built for the source file.


I tried what you suggested but to no avail :( . I'm sure the file is included as part of the source for two reasons:
A) You can only place breakpoint in files that are part of the projects.
B) I have no problem stopping on breakpoint in other functions in the same file! Even if it is a function just before the problematic function or even a function called during the problematic function.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I had this problem and I fixed it by going to Project>Project Properties>Configuration Manager. Somehow, my project was listed there in the release mode, even though I specifically set it to debug mode in the IDE's toolbar. Once I changed it to the debug mode inside the Configuration Manager, it worked like a charm and I never had a single breakpoint skipped.

Share this post


Link to post
Share on other sites
Hello I Had the same Problem recently.

And the way i solved it was:
In the project (startup) go to properties->Compile->Advanced Compile Options
(a round button)

Then uncheck enable optimizations and select debug INFO FULL, Target MAchine "x86" in case you have Intel based computer.

Cheers.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!