Tag Archives: visual c++

c++

Setting Up ZeroMQ C++ On Visual Studio

4 Comments

This article is tested against following version / configuration:

  • Visual Studio 2012 (V110) Platform Toolset
  • Win32
  • ZeroMQ 4.0.4
  • Runtime Library: Multi-threaded DLL (/MD)

Steps to setup ZeroMQ on a Visual Studio C++ project:

  1. Download and install ZeroMQ-4.0.4~miru1.0-x86.exe (or newer) from http://zeromq.org/distro:microsoft-windows
  2. Set ZEROMQ_HOME environment variable to C:\Program Files (x86)\ZeroMQ 4.0.4 (or wherever you installed it to)
  3. On Visual Studio project configuration, add $(ZEROMQ_HOME)\include to Configuration Properties -> VC++ Directories. Don’t forget to restart Visual Studio so it picks up the new environment variable
  4. Add $(ZEROMQ_HOME)\lib to Linker -> General -> Additional Library Directories
  5. Add libzmq-v110-mt-4_0_4.lib to Linker -> Input -> Additional Dependencies
  6. Get a copy of zmq.hpp from , place this somewhere on your project. This header file references zmq.h located at $(ZEROMQ_HOME)\include
  7. Once you’ve compiled your executable, place libzmq-v110-mt-4_0_4.dll on the same folder, otherwise ZeroMQ initialisation will cause runtime crash

And finally take a look at some excellent tutorial examples from zeromq.org website to get you started, in particular:

See Also

c++

Debugging Visual C++ DLL Without Host Application EXE Source Code

Leave a comment

Here’s our situation, the 3rd party app we’re using in our company can be customized by loading a DLL into it, but we (obviously) cannot see the source code of the host exe program, we only have access to our DLL’s source code. The problem is how to debug our DLL when crashes occured?

Yes it’s unfortunate, if the DLL did cause a crash the host exe will go down together with it. Luckily the host exe record some kind of stack trace when it crashed, here’s what it looked like (let’s call our DLL cricket.dll to simplify things):

Filename    : *******
Time        : 2014.11.13 18:41 (74:37:03 elapsed)
Program     : ******
Version     : ******
Revision    : ******
OS          : Windows 7 Server 6.1 Service Pack 1 (Build 7601)
BIOS        : DELL   - 1 - PowerEdge R420
Explorer    : 9.11
ID          : 
Processors  : 24 x Intel Xeon  E5-2420 0 @ 1.90GHz
Computer    : LIVE-SERVER-1:WORKGROUP
Memory      : 29253 free of 32690 Mb
Virtual     : 2639 free of 4095 Mb
Handlers    : 14569
Path        : D:********
Disk D:     : 169325 Mb of 224999 Mb free
Exception   : C0000005 at 70606D91 read to 1FAF001A

Modules     : 01080000 009DD000 d:************.exe (*****)
            : 775A0000 00180000 c:\windows\syswow64\ntdll.dll (6.1.7601.18247)
            : 76EB0000 00110000 c:\windows\syswow64\kernel32.dll (6.1.7601.18409)
....
            : 705F0000 00047000 cricket.dll

Pay particular attention to the Modules section at the bottom. This tells us specific address in memory where our dll was loaded by the host exe. This information will be crucial to determine the relative address further down in the stack trace.

In this instance it told us cricket.dll was loaded at 0x705F0000 and it’s of 0x00047000 bytes length.

Further down the massive stack trace, we can see the record of the particular crash-causing thread:

      crash : #213 0002EFF4 EIP: 70606D91 ESP: 23CEF448 
              70606D91:000000 [70606D91] unknown (cricket.dll)
              705FF5E1:000000 [705FF5E1] unknown (cricket.dll)
              705F90C9:000000 [705F90C9] unknown (cricket.dll)
              705FF1A2:000000 [705FF1A2] unknown (cricket.dll)
              7060D652:000000 [7060D652] unknown (cricket.dll)
              7060D6D0:000000 [7060D6D0] unknown (cricket.dll)
              76EC3378:000012 [76EC338A] AcquireSRWLockExclusive (kernel32.dll)
              775D9F0F:000063 [775D9F72] RtlInsertElementGenericTableAvl (ntdll.dll)
              775D9F0F:000036 [775D9F45] RtlInsertElementGenericTableAvl (ntdll.dll)

crash -->  70606D91 80780F00          cmp        byte [eax+0xf], 0x0
              70606D95 74EB              jz         0x70606d82


          70606D97 8B8310040000      mov        eax, [ebx+0x410]
          70606D9D 89BD24FDFFFF      mov        [ebp+0xfffffd24], edi
          70606DA3 3BF8              cmp        edi, eax
          70606DA5 740E              jz         0x70606db5

          70606DA7 663B770C          cmp        si, [edi+0xc]

What I really wanted to know here is which line of my source code corresponds to the hex code above? First, find out the relative address. In this circumstances, since the DLL was loaded at 0x705F0000, we have to subtract that amount from the address, so 0x70606D91 - 0x705F0000 (in base 16) is 0x00016D91 (you can pull up Windows calculator, set it to Programmer mode if base 16 math is too hard).

Next, prepare the DLL source code of the same version against that crashed on production environment (git tagging will be very helpful here). This also requires the .pdb file of corresponding DLL which hopefully you’ve saved when releasing the code. Keep in mind recompiling the exact same source might produce incompatible .pdb.

Drop the .pdb file into your Release folder, and from Visual Studio select Debug -> Attach to Process... It’ll be easier if you run the exe locally loaded with the exact same DLL that crashed.

Next you’ll need to translate the relative address into the local address of the exe your debugger is attached to. To do this:

  1. Open the Modules window (Debug -> Windows -> Modules)
  2. Find your DLL, take note of its start address

vcppdebug1.

Here my local DLL is loaded at 0F75000, so I just need to add that to the relative address to localize it: 0x0F75000 + 0x0x00016D91 = 0x0F766D91

Next is to find the source code corresponding to that address:

  1. Open Debug -> Windows -> Disassembly
  2. On the address bar, input the localized address 0x0F766D91
  3. Right click on the line, and select Go to Source
  4. Voila! You’ve managed locate the culprit line, now do this for the other location on the stack trace too

vcppdebug2

Big thanks to SO community for helping me with this technique.

c++

Generating Visual C++ Crash Dump For Debugging

Leave a comment

Detecting cause of problem that occurs only in production environment is hard. For Visual C++ created native windows application, this can be done using DebugDiag tool.

Download and install the tool on the production server, run it, and create a Crash rule type

vcppdebug1

Select a specific process target:

vcppdebug2

And search for your process

vcppdebug3

Tick This process instance only if multiple processes with same name are running but you’re only interested in one.

Click next and accept all defaults. Then when the crash occurs, you will get a .dmp file on C:\Program Files\DebugDiag\Logs\Crash rule for process id NNNN folder.

This .dmp file can be copied into your PC and opened in Visual Studio for stack trace analysis. Don’t forget you need to tell Visual Studio where to find the symbol (.pdb) file.

Select Set symbol paths on Visual Studio Action bar and add the folder containing your .pdb file.

vcppdebug4

Then start the debugging session by selecting Debug with Native Only. Visual Studio will tell you the stack trace when the crash happens.

Thanks to Ganesh R for providing this solution on Stack Overflow.

Also checkout Microsoft’s documentation on DebugDiag.