Debugging on Windows

(1.4) By Mark Benningfield (mbenningfield1) on 2022-10-27 23:45:29 edited from 1.3 [source]

I'm developing on Windows (VS2019) and I've got a project that uses SQLite, built as a library from the amalgamation (3.37.2). That library is referenced by a managed library, which is then referenced by the executable.

I'm trying to debug a database issue, and I'm pretty sure I've got the debugger set up correctly, since whenever I try to step into the native code, it pops up looking for the symbol files (sqlite3.pdb).

Here's the rub: it doesn't recognize the "sqlite3.pdb" file produced by the linker as the right symbol file.

I've gone through and deleted all of the "bin" and "obj" directories and done a fresh build from the ground up, and even when I browse right to the "sqlite3.pdb" file the linker just produced 2 seconds ago, it says it's not a matching symbol file.

My next step is to try building from preprocessed sources instead of the amalgamation, to see if it's a linker limitation with the amalgamation, but I'm hoping there's a linker switch I'm overlooking, or something equally simple.

(2) By Chris Locke (chrisjlocke1) on 2022-10-25 11:01:13 in reply to 1.0 [link] [source]

Excuse my ignorance, but are you trying to debug SQLite to work out if that is having a wobble, or are you debugging your application which just uses SQLite? I develop using Visual Studio and use the system.data.sqlite.dll 'wrapper' and don't need symbol files, etc... but this may be because I don't need to debug down to the level you are. However, if you don't either, then ... maybe you don't either (.. that made more sense in my head... ;) )

(3) By Mark Benningfield (mbenningfield1) on 2022-10-25 12:11:26 in reply to 2 [link] [source]

No, I'm trying to debug into the native sqlite3.dll library. The managed libray that references it is a very lightweight managed data wrapper (much leaner than System.Data.SQLite). So, yes I need the debug symbols for the native library.

(4) By Aask (AAsk1902) on 2022-10-25 12:25:52 in reply to 3 [link] [source]

The managed libray that references it is a very lightweight managed data wrapper ...

Is it proprietary or off the shelf? If the latter, what is it? (I'm just curious)

(5) By Mark Benningfield (mbenningfield1) on 2022-10-25 15:06:57 in reply to 4 [link] [source]

It's an in-house wrapper, with very close-to-the-metal interop, and a barebones, minimal entity model. No ADO.Net, no EF or other ORM.

(6) By Warren Young (wyoung) on 2022-10-25 15:20:22 in reply to 1.0 [link] [source]

Between Windows' baroque DLL search path rules, its lack of meaningful versioning, and SQLite's widespread popularity, there's a fair chance your running executable isn't linking to the DLL matching that PDB.

I believe Process Explorer can show you the file path of each loaded DLL when pointed at a running executable.

(7) By Mark Benningfield (mbenningfield1) on 2022-10-25 17:27:18 in reply to 6 [link] [source]

I know, that's why the sqlite3.dll is co-located with the executable. Both the .pdb and the .dll produced from the native sqlite3 project are.

(8) By Warren Young (wyoung) on 2022-10-25 17:31:41 in reply to 7 [link] [source]

Follow the ABCs of troubleshooting:

Assume nothing
Believe no claim until it's verified
Check everything

Until you see that path appear in Process Explorer, you're failing on steps A and C.

(9) By Mark Benningfield (mbenningfield1) on 2022-10-26 02:15:00 in reply to 8 [link] [source]

I agree completely. I forgot to mention that I had already verified the load path with the "Modules" window in the VS debugger. But, in the interest of turning over all the stones I can find, I ran ProcExplorer and verified that the expected load path was the same.

Browsing the Properties tab for the dll in ProcExplorer, I found that it does indeed have the wrong timestamp. Now I just have to figure out where it's coming from and how it's getting there, as there are no build events defined for ANY project in the VS solution (Double-checked for the 10th time).

The project was very recently upgraded from VS2015 to VS2019 (upgrade in place), so I may end up building a new source tree from scratch, one project at a time, if I can't nail down where the old dll copy is coming from.

Thanks for the help. At least I'm making progress now.