While you should always have your PDB files in symbol servers, there are times when you’re doing private (aka local) builds and moving those builds around hither and yon in a test environment where you can accidentally forget to copy over a binary’s PDB file. That leads to the common question: short of starting a debugger, how can I check that a PDB file matches a particular binary?
Obviously you can always take an educated guess if a PDB file matches a binary from the timestamp. That will work in most cases, but to completely check, you’ll need to rely on SYMCHK.EXE, a command line tool that comes with the Debugging Tools for Windows (AKA WinDBG). The trick is to tell SYMCHK.EXE to use the PDB file directory as your symbol server. In the following example, I’m running the SYMCHK.EXE command from the same directory where my binary, RinjPlay.exe is located.
symchk RinjPlay.exe /s .
If the PDB matches the binary, you’ll see the following output.
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
If the PDB does not match, your output will look like the following.
SYMCHK: RinjPlay.exe FAILED – RinjPlay.pdb mismatched or not found
SYMCHK: FAILED files = 1
SYMCHK: PASSED + IGNORED files = 0
As with any SYMCHK.EXE command, you can pass /v to get detailed output about your binary and PDB file matching.
The Atmosera CMP is made up of the Azure ARM portal, Terraform, Chef, and proprietary powershell/logic/web-apps that allows our operations team to stand up infrastructure incredibly quickly.
There is a frontend web application that allows operations team members to input pertinent details to the build (see screenshot).
The application then creates the JSON formulation of the environment and invokes Terraform to complete the build. Once complete the infrastructure is stood up then is ready for desired state configuration. We have many cookbooks which are capable of configuring completed infrastructure to any number of final states including: Domain Controller, IIS, SQL, etc.