0

The program runs perfectly in Visual Studio 2013, but as soon as I try to run the executable directly from Explorer, the application crashes.

I ran it with WindDbg, and it gave me this error code:

Microsoft (R) Windows Debugger Version 10.0.10240.9 X86
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine:
G:\Libraries\VSProjects\UntitledGame\UnicityEngine\bin\Debug\UnicityEngine.exe
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is: 
ModLoad: 012f0000 01384000   Demo.exe
ModLoad: 76f10000 77090000   ntdll.dll
ModLoad: 767a0000 768b0000   C:\Windows\syswow64\kernel32.dll
ModLoad: 76670000 766b7000   C:\Windows\syswow64\KERNELBASE.dll
ModLoad: 198b0000 19978000   C:\Windows\SysWOW64\OPENGL32.dll
ModLoad: 766f0000 7679c000   C:\Windows\syswow64\msvcrt.dll
ModLoad: 76a60000 76b01000   C:\Windows\syswow64\ADVAPI32.dll
ModLoad: 74ff0000 75009000   C:\Windows\SysWOW64\sechost.dll
ModLoad: 76340000 76430000   C:\Windows\syswow64\RPCRT4.dll
ModLoad: 74880000 748e0000   C:\Windows\syswow64\SspiCli.dll
ModLoad: 74870000 7487c000   C:\Windows\syswow64\CRYPTBASE.dll
ModLoad: 754d0000 75560000   C:\Windows\syswow64\GDI32.dll
ModLoad: 76570000 76670000   C:\Windows\syswow64\USER32.dll
ModLoad: 752b0000 752ba000   C:\Windows\syswow64\LPK.dll
ModLoad: 74ba0000 74c3d000   C:\Windows\syswow64\USP10.dll
ModLoad: 083e0000 08402000   C:\Windows\SysWOW64\GLU32.dll
ModLoad: 6f500000 6f5e7000   C:\Windows\SysWOW64\DDRAW.dll
ModLoad: 6f640000 6f646000   C:\Windows\SysWOW64\DCIMAN32.dll
ModLoad: 75020000 751bd000   C:\Windows\syswow64\SETUPAPI.dll
ModLoad: 75280000 752a7000   C:\Windows\syswow64\CFGMGR32.dll
ModLoad: 751e0000 7526f000   C:\Windows\syswow64\OLEAUT32.dll
ModLoad: 74c40000 74d9c000   C:\Windows\syswow64\ole32.dll
ModLoad: 74940000 74952000   C:\Windows\syswow64\DEVOBJ.dll
ModLoad: 71390000 713a3000   C:\Windows\SysWOW64\dwmapi.dll
ModLoad: 75590000 761db000   C:\Windows\syswow64\SHELL32.dll
ModLoad: 74da0000 74df7000   C:\Windows\syswow64\SHLWAPI.dll
ModLoad: 0ff90000 10059000   C:\Windows\SysWOW64\MSVCP120D.dll
ModLoad: 0f200000 0f3bf000   C:\Windows\SysWOW64\MSVCR120D.dll
(5fc.14b4): Break instruction exception - code 80000003 (first chance)
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll - 
eax=00000000 ebx=00000000 ecx=13640000 edx=0014e218 esi=fffffffe edi=00000000
eip=76fb12fb esp=0029f414 ebp=0029f440 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
ntdll!LdrVerifyImageMatchesChecksum+0x96c:
76fb12fb cc              int     3`

I have absolutely no idea why this happens. I use GLEW and GLFW, if this is of any importance.

Update

After running through the exceptions once more, here are all unhandled exceptions thrown by the program:

0:000:x86> gn

(f40.1758): Access violation - code c0000005 (!!! second chance !!!)

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\SYSTEM32\wow64.dll - 

wow64!Wow64LdrpInitialize+0x8d5:

00000000`7318cb49 654c8b1c2530000000 mov   r11,qword ptr gs:[30h]

gs:00000000`00000030=????????????????

0:000> g

(f40.1758): Access violation - code c0000005 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

atioglxx+0x12f0:

690212f0 8a01            mov     al,byte ptr [ecx]  

ds:002b:cccccccc=??

0:000:x86> gn

(f40.1758): Access violation - code c0000005 (!!! second chance !!!)

wow64!Wow64LdrpInitialize+0x8d5:

00000000`7318cb49 654c8b1c2530000000 mov   r11,qword ptr gs:[30h] 

gs:00000000`00000030=????????????????

0:000> gn
Ilya Kurnosov
  • 3,180
  • 3
  • 23
  • 37
Mokka
  • 1
  • 2
  • The debug spew above doesn't contain the error. Did you actually run the app in the debugger? You need to figure out why it fails. Look in the event log for exceptions or set up your JIT debugger to catch the first chance exception. – Brian Rasmussen Sep 18 '15 at 21:23
  • Does your debug work and your release version crash? Or does your debug version work but only when it is ran directly under Visual Studio debugger? – StarPilot Sep 18 '15 at 21:23
  • Oh and since it is hitting a breakpoint, does it really "run perfectly" in the debugger? Or do you hit Continue a few extra times? – Zan Lynx Sep 18 '15 at 21:25
  • @StarPilot Both settings do work in VS, but not when launched directly form the explorer. – Mokka Sep 18 '15 at 21:33
  • Another thing that might make it appear to work under the debugger is if you have something like "continue on exceptions" checked. I think that `int 3` raises a SEH exception in Windows and the debugger can be told to ignore those. Change it to break on ALL exceptions and don't ignore any of them. – Zan Lynx Sep 18 '15 at 21:35
  • @ZanLynx did that: Look below – Mokka Sep 18 '15 at 21:57
  • 1. see [How to set up symbols](http://stackoverflow.com/questions/30019889/how-to-set-up-symbols-in-windbg) 2. You have a 64 bit dump of a 32 bit process, see [How to take a good crash dump for .NET](http://stackoverflow.com/questions/24874027/how-do-i-take-a-good-crash-dump-for-net) 3. It looks like a breakpoint. Do you run a debug build and have a `Debugger.Break()` statement somewhere? – Thomas Weller Sep 18 '15 at 23:23
  • An access violation in C++ is a pointer that refers to memory which does not belong to your application. In C#/Java you'd call that a NullReferenceException or NullPointerException. – Thomas Weller Sep 18 '15 at 23:35

1 Answers1

0

That int 3 it stopped on? That is the interrupt that drops the program into the debugger. Or kills it as you are seeing.

It looks to me that you (or someone) put an intentional debug break instruction into your code.

See https://msdn.microsoft.com/en-us/library/f408b4et.aspx

It appears you can also get this if you try to call a function pointer that is pointed into memory that contains 0xCC, which is one of the debug mode memory fillers I believe.

See When and why will an OS initialise memory to 0xCD, 0xDD, etc. on malloc/free/new/delete?

Community
  • 1
  • 1
Zan Lynx
  • 53,022
  • 10
  • 79
  • 131
  • Thank you. I will set up WinDbg as a postmorten debugger right now. It seemed to me, asi if any of the symbols would fail to load, but as it seems, they are not guilty – Mokka Sep 18 '15 at 21:34