Dmitry Pilugin gives us a specific example of using WinDbg to track down a bug in SQL Server:
The important part is that the same stack with the same relative to a module addresses was in all the dumps.
To get an idea of what is going on, we may try to convert the relative address: Module(<sqlmodule>+hex), into a SQL Server’s method name. Probably the method’s name would be descriptive enough to give some information. This is the moment where WinDbg with public symbols may help.
You may download WinDbg from the here, and then download public symbols, you may use WinDbg documentation or here is an example of how to do it from Paul Randal, adopt it to your folders and version.
You should not debug a production server, because WinDbg will break any singe instruction execution, so make sure you have a test server with the exact same SQL Server version as production (in my case it was 13.0.4474.0).
I heartily second the comment that you never want to run the debugger in production.