When did I build this DLL?

When did I build this DLL?

When working closely with customers at Simul, often multiple revisions of the same-named DLL can be sent for the customer to test and confirm that the fixes or features are working correctly. In the melee of the rapid iteration, you can easily lose track of the date the DLL was built. How do you confirm when the DLL was built, so that everyone is talking about the same binary?

Visual Studio’s Developer Command Prompt and DUMPBIN

A quick Windows search should bring up the option to launch the Developer Command Prompt for VS 2022 (… or whichever version you have installed). Opening it naturally, opens a special command prompt configured to allow command line access to Visual Studio’s build tools and helper utilities; DUMPBIN is just one of these.

Developer Command Prompt for VS2022 showing the help page for DUMPBIN

DUMPBIN Commands - Looking at the Headers

To get the build date and time of the binary, use the /HEADERS option and supply the path to the binary file in question, e.g. DUMPBIN /HEADERS [filepath], and see the example below. We’re interested in the ‘FILE HEADER VALUES’ section, specifically the ‘time date stamp’. Here we can see finally the build date and time.

Developer Command Prompt for VS2022 showing DUMPBIN /HEADERS "C:\Users\Andrew\source\repos\MIRU\bin\x64\Debug\MIRU_CORE.dll"

More Data and the Docs!

Full documentation on DUMPBIN can be found on this page: https://docs.microsoft.com/en-us/cpp/build/reference/dumpbin-options?view=msvc-170. There are a lot of options available just within DUMPBIN such as /SYMBOLS and /DISASM to get more information on the binary and in conjunction with WinDbg and Dependencies, you can really start to debug and understand issues with binaries in your program.

Crashing inside the Vulkan Loader and Validation Layer - Symbols and Source

I’m sure at some stage in your development cycle while using the Vulkan graphics API you will crash either in the Vulkan Loader or the Vulkan ValidationLayer. As frustrating or cryptic as this might be, there are tools to peek behind the curtain and see what has gone wrong.

Firstly, I should distinguish between the ‘loader’ and the ‘validation layer‘. The first loads the function pointers from the driver for the Vulkan API calls to communicate to the graphics hardware; acting as a simple intermediary. On Windows, this is the vulkan-1.dll, which is found in the C:\Windows\System32 folder, and the application will link against this via the vulkan-1.lib provided in the Vulkan SDK. The second sits in between your application and vulkan-1.dll and injects certain checks to validate that the Vulkan calls are compliant with the Vulkan specification. Located in the Vulkan SDK, VkLayer_khronos_validation.dll is dynamics loaded when requested by the system or application to work its magic.

Source and Symbols?

Ok, the details! Here’s where to find the source and the symbols for both the loader and the validation layer.

Loader: The vulkan-1.pdb can be obtained from the Vulkan Runtime download on the LunarG Vulkan SDK download page. The source can be obtained from KhronosGroup’s GitHub repo: Vulkan-Loader. When downloading both the source and symbols, you must ensure the versions match the vulkan-1.dll binary (this can be easily checked in the Modules window of Visual Studio while debugging) such that if the vulkan-1.dll binary is 1.3.204.0, then the Runtime/Loader must also be 1.3.204. You can select the correct version from the branch dropdown menu on GitHub, and the correct version from the LunarG Vulkan SDK download page.

Validation Layer: The VkLayer_khronos_validation.pdb is already located in the /Bin folder of the Vulkan SDK - lucky us! The source can be obtained from KhronosGroup’s GitHub repo: Vulkan-ValidationLayers. When downloading the source, you must ensure the version matches the SDK i.e. if the SDK is 1.3.204.0, then the ValidationLayer must also be 1.3.204. You can select the correct version from the branch dropdown menu on GitHub.

Starting the debugger…

Starting the debugger…

Well, It’s New Year’s Eve today and also just over three years since I started my Software Development career at Simul. In that time, I have learnt an inordinate amount of stuff about graphics programming. Following Roderick Kennedy’s suggestion, I have started a blog, where I’ll be detailing my thoughts on programming in general from the moments of brilliance to the down-right infuriating. I will try my best not to make this a place where I’d vent frustrations on some topic or another; rather better to praise and/or critique the stuff I am working on.

‘So, who are you and what have you done?’

Well, I’m Andrew Richards - A self-taught C++ Software Developer focusing on Graphics with D3D12 and Vulkan, and this is my blog called Programming Development Blog - It’s symbolic. - ‘Self-taught, you said?’ Quite! In fact, I studied Music at University. So, I hope to bring a different perspective to this world that I accidentally stumbled into. However, I am by no means solely a creative person, along with my studies in Music I am well versed in the rigour of Mathematics and Physics. In short, I consider myself more of a poly-math with a ferocious appetite for knowledge. I have been working at Simul since December 2018 on trueSKY, a rendering plugin for realistic clouds and atmospheres. I haven’t limited my scope of programming to Simul-related work, but instead expanded it to my personal projects such as MIRU and GEAR, which are my rendering unit and game engine receptivity. I do have a habit of wanting to write everything from scratch, such as MARS my mathematics library. It offers a great insight into how best to design an interface for clarity of coding.

’Ok, Cool… So, what are you working on?’

Well, it’s hard to discuss Simul-related work in any detail, so I’ll only talk about stuff that I am working on personally or that’s very generalised. So, some specifics (and hopefully future blogs); I am working a lot on getting Android to build and debug in Visual Studio with Google’s Android Game Development Extension. A deep dive into hardware-accelerated raytracing and its implementation in D3D12 and Vulkan within MIRU. In fact, I want to add new updates or extensions for D3D12 and Vulkan. Working with Xbox UWP application and much more. I hope you stick around to listen to this developer’s stories. See you in the next post.