views:

272

answers:

3

I am attempting to debug a dll that is called by a Labview application. I have the right symbol files (downloaded from microsoft) for things like ntdll.dll and others. I of course also have the pdb file for my DLL. What I don't have, obviously, is any symbol files for labview; since as far as I know National Instruments does not release.

I have tried a simple test app calling a dll from within windbg.exe. This works well. When I add labview into the mix windbg of course starts giving ERROR: Symbol file not found for all the labview stuff. I am sure I have the right symbol file directories set and source folders are set as well. I am sort of a newb to windbg, but I'm starting to gather that unless you have ALL the symbol files you're hosed on using it. Is that correct? If so I guess it's back to fprintf and limited debugging.

I don't want to use visual studio because this is for a semi embedded application and it simply doesn't have the disk space/room for holding all of visual studio.

+2  A: 

You need to attach the windbg to the LabVIEW process, then set a breakpoint in your DLL code. This way, you will only break when it gets to your code. This is how it works from Visual Studio and a quick search seems to suggest it will work with windbg as well.

CookieOfFortune
+2  A: 

You won't necessarily be hosed if you're only planning on setting breakpoints and whatever in your DLL. That should work fine. Stack traces from your DLL back into the LabVIEW image will start complaining, but hopefully it's stuff you're not interested in anyway and you can just ignore it.

Michael Burr
I found all I needed to do was open the source, set a break point, and "launch" the labview application from Windbg. It turns out that although I thought I had my paths set right one of them was wrong and causing me all my trouble. Thanks!
A: 

You can also set a breakpoint in windbg to break as soon as your DLL is loaded. To do this, attach windbg to the Labview process and use the following command: sxe ld foo(where foo is the name of your dll). This tells the debugger to break when the dll load event occurs, specifically for your dll. See http://msdn.microsoft.com/en-us/library/cc266379.aspx for more info. When you hit this breakpoint you can then figure out which symbol you would like to break on within your code to debug.

nithins