1

In my VS2022 C++ project, something goes wrong after some time. Because the error occurs after 10 minutes only, I need to inspect the call stack to see what went on before the error occured.

However, the call stack is too small.

It just shows this:

enter image description here

I have set break points manually to follow it back, so I know that there are several of my own functions before "ProcessTxtLine" (which is shownn in the call stack), but in the call stack they are not there. So I can not double click them in order to get there quickly.

Because I don't know what else might be important, I am posting a screenshot of my entire VS 2022 window.

Thank you.

enter image description here

Edit:

According to a suggestion, I clicked the first entries, then selected Load Symbols.

However, that did not help. It does show some more, but still not "my" calls.

enter image description here

tmighty
  • 10,734
  • 21
  • 104
  • 218
  • 1
    How is your `ProcessTxtLine` function called? Do you call it directly from your own code? Is that code built with debug information? Or is it through a callback from some other code? Is *that* code built with debug information? You *are* running a debug build? – Some programmer dude Oct 12 '22 at 23:48
  • Yes, I am running a debug build. ProcessTextLine is a function of a class. I do call it directly from my code. I don't know if I built it with debug info. How do I know that? – tmighty Oct 13 '22 at 00:12
  • If the *something* that went wrong smashed the stack, all bets are off. You might not be able to get a valid stack. The backtrace is a great tool when you can get it, but sometimes you have to figure out how to trap the problem before it happens. – user4581301 Oct 13 '22 at 00:13
  • 1
    `0xDDDDDDDD` is a magic debugging code that your compiler added in debug mode to help your debugging. It means already freed heap memory: [https://stackoverflow.com/questions/127386/what-are-the-debug-memory-fill-patterns-in-visual-studio-c-and-windows](https://stackoverflow.com/questions/127386/what-are-the-debug-memory-fill-patterns-in-visual-studio-c-and-windows) – drescherjm Oct 13 '22 at 00:53
  • I just re-read the begging of your question, and looking at the longer callstack: You are probably simply out of memory for your process. Since this is a 32bit process, it can only access 2GB or 4GB (https://stackoverflow.com/a/639562/758345) of virtual memory. Did you check the memory consumption of process when it crashes? – Chronial Oct 16 '22 at 18:29

1 Answers1

6

The message in the callstack is the relevant hint: You need to load more debug symbols for the callstack to be displayed correctly. You can right-click on the first entry in the callstack (the KernelBase.dll... line) and select "Load symbols". You might have to load symbols for more modules than this, but you should get new messages telling you about this.

This issue is unique to 32bit applications. Due to the way the 32bit calling convention works, it is not possible to generate a call stack without debug symbols for all the topmost stack entries. If you compile your application for 64bit, this problem will go away.

Chronial
  • 66,706
  • 14
  • 93
  • 99
  • I am sorry that I had to un-check your answer. I will update my post with new observations. – tmighty Oct 13 '22 at 00:29
  • I think you are still missing symbols. You should expand those "External Code" blocks by right-clicking on them and selecting "Show External Code" – Chronial Oct 13 '22 at 00:38