Group Policy options will let you disable the button for error reporting to Microsoft (Check online for a solution and close the program) but there is no option in Group Policy to disable the debugging button. To disable the “Debug the program” button that is shown in the Windows Problem Reporting window after a program crashes, there are two registry entries that must be modified. One controls it for 64-bit program crashes and the other for 32-bit program crashes:
Under each of these keys, you will see a string titled Debugger. Rename it (e.g., Debugger.bak) and the debug button will no longer show up.
Strange issue with Windows Update occurred. In this case Windows Server 2012 R2 was trying to install 2 updates for Office 2010 but was failing.
KB4461579 failed with Code 780
KB2553332 failed with Code 780
First it turned out that a 64-bit version of Microsoft Access database engine 2010 had managed to get installed which does not play nice with 32-bit versions of MS Office on the same machine. The 64-bit engine was uninstalled and then replaced with the 32-bit version. When the 64-bit version was uninstalled, it also removed the 64-bit version of the Office Source Engine service from the system that was showing up in services.msc. However after this change, the 2 Windows updates listed above were still failing.
Also installed on the system was Microsoft Access 2010 Runtime. Within Programs and Features of the Control Panel, performing a Change->Repair option on it completed fine, but wanted a reboot. After rebooting, the two Windows updates listed above were then able to complete successfully.
Background information: swapped out a CPU during an upgrade (old CPU DDR3-1333, new CPU DDR3-1600).
After that the system was booted using an Ubuntu Live CD without any obvious problems, but ESXi installer was crashing with Pink Screen of Death (PSOD). Next step was to test with MemTest86 (in this case V8.1 build 1000). The system would repeatedly freeze on Test 0 [Address test, walking ones, 1 CPU] with no errors reported. To fix, all that was needed was a CMOS / BIOS reset (to defaults). After that MemTest86 and ESXi installers ran through without any problems.