For issues involving heap corruption on Windows, it\'s necessary to enable a number of global flags on an application so Synergex can get additional information from a dump file. To do so, you\'ll need two programs: GFlags and AppVerifier, which are included in the Windows SDK. If you have Visual Studio on your machine, these files might already be installed. Please note that AppVerifier can report unrelated and benign issues, and not all Microsoft or third-party software works with GFlags and AppVerifier. 

If you have Visual Studio, check the following paths for gflags.exe:

32-bit: C:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x86\\gflags.exe

64-bit: C:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x64\\gflags.exe

And check these paths for appverif.exe:

32-bit : C:\\Windows\\SysWOW64\\appverif.exe

64-bit: C:\\Windows\\System32\\appverif.exe

If you don\'t have these files, you can download them as part of the Windows SDK. You can find the SDK here: developer.microsoft.com/en-us/windows/downloads/windows-10-sdk. When you install the SDK, make sure to select the “Debugging Tools for Windows” feature. If you already have a Windows SDK installed but can’t find GFlags or AppVerifier, modify the installation and make sure that “Debugging Tools for Windows” is selected.

Once you confirm that these applications are installed, follow the steps below to configure these applications and generate a dump file. Note that GFlags and AppVerifier save settings for a given program to the Windows registry. So once you’ve worked through steps 1-3 and enabled GFlags and AppVerifier for a given program, you don’t need to repeat those steps unless you subsequently remove the settings.

1. Determine which EXE file is corrupting the heap. If heap corruption is occurring in a traditional Synergy application, the EXE file could be dbr.exe, dbs.exe, dbrpriv.exe, dbspriv.exe, dbssvc.exe, or rsynd.exe. If heap corruption is occurring in a Synergy .NET application, the EXE file is probably the application itself, although it might be something like w3wp.exe if the application is hosted in IIS. If you are debugging an IIS app or another program that runs in elevated mode or with different user credentials, be sure to note the caveats for steps 5 and 9 before attempting to reproduce the error.
   
   
2. Run gflags.exe, making sure you use the same bit size as the EXE file from step 1. For example, if you’re building a Synergy .NET program in the “Any CPU” configuration with “Prefer 32-bit” checked, run the 32-bit version of GFlags. You can launch GFlags from the Start menu by typing “GFlags”. It will show up in the list as “Global Flags (X64)” or “Global Flags (X86)”. (Other architectures such as ARM may also be listed, but for normal Windows apps you’ll want the x86 or x64 version.)
   
   Once GFlags is open, go to the Image File tab, type the name of your EXE file in the Image field, and press the Tab key. Then select options as shown in Figure 1 (be sure to select “Enable application verifier”), and click OK.
   
   
   Figure 1
   
   If you get a registry error while trying to set these flags, see "Registry error when setting global flags" below.
   
   
3. Run appverif.exe, making sure you use the same bit size as the EXE in step 1. You can launch this from the Start menu by typing “Application Verifier” or “AppVerif”, but note that the 32-bit version is called “Application Verifier (WOW)”.
   
   In AppVerifier, click on the name of your application. It should be listed the same way you typed it in GFlags:
   
   
   Figure 2
   
   Check the boxes for “Basics” and “Miscellaneous” and any other box requested by Developer Support.
   
   You may also want to catch backward overruns. To do this, expand the Basics element and highlight the Heaps option. Then select Edit > Properties, select the Backward option (on the "Application Verifier - Properties" window), and click OK to save the settings.
   
   When you\'re done configuring AppVerifier, click Save and then click Exit.
   
   
4. If you’re debugging a traditional Synergy application, set SIG_CORE=1 in the environment you use to launch the program. If the traditional application is running as a service, set this in the system environment and reboot before proceeding.
   
   
5. Launch the program you want to debug, and attach a debugger. We recommend that you use the Visual Studio debugger and that you attach to the process before the error occurs. Alternatively, you can generate a dump file with another debugger, such as WinDbg or ProcDump, or by attaching a debugger after the program has crashed. If you do use something other than the Visual Studio debugger, be sure to get the logs from AppVerifier (see step 9 below).
   
   To attach to your program with Visual Studio, open a new instance of Visual Studio and click the “Attach…” button or Debug > Attach to Process. Then, in the Attach to Process dialog, click the “Select…” button and select Native. Finally, select your program from the "Available processes" list and click Attach.
   
   Note that you must run Visual Studio in Administrator mode in order to debug an IIS application or any other application running in Administrator mode. You may also need to check the "Show processes from all users" box in order to find the right process.
   
   
6. Once you\'ve attached the debugger, run the program until it crashes. Then generate a dump file. In Visual Studio, for example, select Debug > Save Dump As.
   
   Depending on the type of issue that AppVerifier catches, you may be able to continue. (Some problems, such as access violations, won’t allow you to continue.) Before continuing from an exception, be sure to copy all information in the Visual Studio Output and Call Stack windows, and be sure to get a dump file.
   
   
7. After generating the dump file(s), gather a copy of the EXE and all assemblies (DLLs and PDBs) used by the program, including all the Synergy assemblies involved. These files need to be in one directory so Developer Support can go through the dump file. If you open a dump file in Visual Studio and look at the Modules window (Debug > Windows > Modules), it should list all of the EXEs and DLLs the application was using at the time of the crash. You can omit any DLLs that are part of Windows (anything with System32 or SysWOW64 in the path), but you should include all other listed EXE and DLL files, along with corresponding PDB files. If this is a traditional Synergy application, include any DBR and ELB files used by the application.
    
8. Make sure the dump file is for the right executable. Open the dump file in Visual Studio or WinDbg and check that the dump is for the executable you set up for GFlags and AppVerifier. If bit size is important, open the dump file and verify that the paths of the DLLs in the Modules area are for the right bit size.
    
9. There may be additional information in the AppVerifier logs. In AppVerifier, click "View > Logs". You should see something similar to Figure 3 below. If you select the application that you’ve been debugging, the window should list a log for each time the program was launched after enabling AppVerifier. The error column lists the number of errors that AppVerifier encountered in that instance of the program. If the count is 1 or more, the log may contain additional necessary debug information. Click the View button to view the existing log file in XML form, or click Save As to save a separate copy as an XML file.e.
   
   
   Figure 3
   
   Note that AppVerifier may have trouble generating logs for protected processes (such as w3wp.exe for IIS). To work around this for w3wp.exe, try this:
   
   Change the protected process log path to a location that w3wp.exe can already write to, by running this from a Command Prompt:
   
   appverif -sppath C:\\temp
   
   When you run w3wp.exe, it will create files named C:\\temp\\w3wp.exe.X.dat (where X is an integer starting with 0).
   
   Copy these files to the default AppVerifier log location: C:\\Users\\username\\AppVerifierLogs
   
   For more information, see https://blogs.msdn.microsoft.com/dougste/2010/01/11/generating-application-verifier-logs-for-web-applications/.
   
   
10. Send all applicable files to Synergex: dump files, EXEs, DLLs, PDBs, DBRs, and log files (XML).
     

Registry error when setting global flags

You may get an error related to the registry when trying to set the global flags for a program. For example:

Figure 4

If this happens, you can fix this by opening the Windows Registry Editor (RegEdit) and adding an empty “Image File Execution Options” key for the program:

1. For a 64-bit program: HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\program.exe 
   
2. For a 32-bit program: HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\program.exe

Always be careful when modifying the Windows registry, and consider making a backup before making any changes.

You may get a similar error if you try to unset flags after debugging a heap corruption. In that case, you could try deleting the registry key above, or clearing all check boxes for the program in AppVerifier and GFlags. For more information, see https://stackoverflow.com/questions/25533827/registry-key-for-global-flags-gflags.