What are these hex strings that I see on call stack in visual studio

Question

I see these hex strings which do not seem to belong to any dll in the call stack of visual studio:

000000001665b7e0()
0000000000000935()
0000094500000001()
000000001665b9a4()

Normally I would see something like :

libabc.dll!myclass:myfunction() Line76

What do they imply and how do I make meaning of them ?

Answer 1

Those are indeed functions, but no one has left "breadcrumbs" your debugger can use to translate those addresses into a function name.

In this case, the mapping between 000000001665b7e0 and a function name is either in a symbol file which you do not have, a symbol file your debugger is unaware of, a symbol file your debugger is unable to read, or such a mapping does not exist.

What can you do about it?

Find the symbol information for this function and point your development system at it or ignore that you do not have this information.

The former is tricky because you have no clue what the function is. You may have to use a shotgun approach, add all the libraries, but you can reduce the scope of the search if you know what libraries your program uses.

The latter is a viable option because if you don't have access to the debugging information odds are pretty good you can't do anything about any bugs made by whoever wrote the code. Maybe you can write them a nasty e-mail. For an established library it's more likely there is no bug in the library, and your program is using the library incorrectly. Check the library documentation and debug your code first. When you have eliminated the possibility of errors in at your end, then start digging into the third-party code. With an established library there is often a core of developers who will be able to help confirm and resolve a library bug.

Why this happens:

The computer doesn't care what people call things. The computer only cares where things are in memory, so to make the smallest output file possible, the development system's (AKA "IDE", "compiler", and "tool chain" with varying degrees of accuracy) build tools typically strip out all of the stuff that's unnecessary to run the program. The nice, human-readable names sane programmers give functions, variables, classes, and what have you are among the first things to go.

The development system usually will allow you to preserve this address-symbol mapping to make debugging easier. As you've seen raw hex numbers aren't much use without some way to map them to recognizable terms you can use to look up documentation. Depending on the build system, this information may be left in the executable or library (resulting in a much larger output file) or it may come on the side as an optional symbol information file. These mapping files are often specific to the development system and are not readable by other development systems.