-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
symbols / pdb files. #111
Comments
You should be able to just pass in the _NT_SYMBOL_PATH environment variable in the docker run command. I believe this should work (untested): Let me know if this works for you! |
Does this work for symbol files that reside on my local windows system? |
It does not work with symbol files that reside on your local disk. Because from within the container, there is no general access do your host-system disk, except for folders that are mounted in. Things you can do:
|
I'm quite excited about superdump, I have been experimenting with it during the last couple of days. I had to familiarize myself first with windbg as I was running into a lot of problems that were not related to superdump. However I have now reached a point where I am stuck because I don't know docker/superdump that well. I have a minidump that works just fine when using windbg on my local machine. If I use the same minidump in superdump, it can't find any of the symbols, except for the windows ones. However, if I first populate the symbol cache folder (which I bind via the -v option) with my local windbg then superdump (sometimes) works. Sometimes, because a lot of times, superdump will crash with outofmemory, or outofstack or some other error message. Is there a limit on the number of DLLs/PDBs that can be loaded? |
@andresod great that you like the project :) Which deployment do you use?
Can you share your symbol path and how you did set it? How did you start SuperDumpService? In cases 2. and 3., I'd recommend to omit SuperDumpService at first. Use First, yet If you get an OOM here, we need to debug this :). If the it runs through and If that works, try to start SuperDumpService with For uploading .pdb files within a zip, you additionally need to adapt a setting in |
@discostu105 thanks for the quick reply. I'm using the docker-image. Where can I download the release binaries? This is how I run the container: I use the same setting for _NT_SYMBOL_PATH when using the standalone windbg on my machine locally. I was wondering if it perhaps has something to do with permissions, i.e. the docker image might not be able to access our symbol server -- it kind of works when I populate the sym_cache folder (same one I bind to in the run cmd) by running the standalone windbg first. However, I have no issues accessing the symbol server using a nanoserver container. I will try building superdump.exe myself (in case I can't obtain the release binaries) and try your suggestions for 2 and 3. Regarding the setting for .pdb files within a zip, I assume this requires building the binaries or is there a way to supply this setting via the run cmd? |
You can find Releases here: https://github.com/Dynatrace/superdump/releases Just published a new version (3.0) with all the latest features included. |
I've also pushed the latest version to docker hub. Then I tried this command (which IMHO should be correct): However, I'm also having trouble retrieving my private symbols. I think it is an issue that only occurs from within docker images, so a workaround for you might be to go without docker for now. If you want to dig further into the docker/symbolserver issue, I recommend uploading a dump, then enter the "Interactive Mode". You can go with all sorts of WinDbg commands in there, but it actually runs inside the docker container. |
thanks @discostu105 the release binary works much better than the docker image. in superdump windbg.log it only shows mymodule!myfun+0x96 Web Terminal That is, no windbg interactive session is started. I'm probably missing one of the dependencies. btw, there was no need for me to upload the pdbs alongside the crashdump file -- superdump was able to find the pdbs via the symbolpath. |
Concerning Concerning "inlined" functions: these are not shown in SuperDump reports for some reason, which is a kown issue: #54 Interactive Mode: Open browser dev-tools (F12) and look for the websocket connection under |
thanks again for your prompt response! I have cdb installed at the standard location, which matches the path in appsettings.json. [solved] after changing both the ASPNETCORE_URLS to you are right, cdb seems to be generating different info when using the |
The websocket/https problem: It's a bug here: https://github.com/Dynatrace/superdump/blob/master/src/SuperDumpService/wwwroot/js/webterm.js#L83 For https, the connection needs to be made to Currently the list of WinDbg commands is hard-coded. Feel free to add that argument to the code, it sounds useful anyway. Another option would be to make the list of commands configurable in a separate file. |
by now, this discussion has deviated from the initial report about symbols/pdb files - is it OK to continue here or should I create a new issue? |
Sure, feel free to do a PR! |
It seems that the interactive session is not able to find those pdbs that are packaged, unless I add the following to the sympath: Obviously, path above is installation dependent. Would it be possible to somehow add this in code using a relative path? Superdump is able to 'find' the pdbs during initial analysis, just not in the interactive session. |
I have superdump up and running. Thank-you, this looks like just what I need.
Unfortunately, I am unsure how to set the symbol path to include my pbd files.
Do I need to edit a Dockerfile and rebuild?
Any help here is most appreciated.
The text was updated successfully, but these errors were encountered: