Vista Data Execution Prevention stops LOVE engine from running

Issue #23 invalid
Anonymous created an issue

Exactly what the title says: Vista's Data Execution Prevention halts LOVE engine from running, which prevents those who don't have admin access from using the software, and is inconvenient (and a little unnerving!) for those of us who do have admin access.

Plus, I'm always a little leery about anything that triggers antivirus measures, but doesn't explain why that happens...

Comments (20)

  1. Anonymous

    Correction: even WITH admin rights, I can't turn off DEP for the LOVE engine. So, completely non-functional on Vista :(.

    Note: only tested with the binary distribution, didn't test the source distro.

  2. Anonymous

    I'm having the same issue. When you launch love, it immediately crashes and tells you that Data Execution Protection was activated and stopped the program. When you try to add love to the DEP exclusions list you get an error message:

    "This program must run with data execution protection (DEP) enabled. You cannot turn off DEP for this program."

  3. itsnotabigtruck
    • changed status to new

    Reopening due to another user experiencing the issue.

    No repro on Windows 7 (x64) or Windows Vista (x64) with DEP set to opt-out. The DEP mode shouldn't matter anyway, as LÖVE is flagged to always run with DEP enabled - that's why it won't let you add it to the exceptions. Does LÖVE crash no matter what (e.g. on the default "nogame"), or does the problem only occur with certain apps? Also, are you running the x64 (64-bit) version or the ordinary x86 (32-bit)?

  4. Anonymous

    I, too, am having this problem when running LÖVE on Windows Vista (32-bit). It crashes on startup no matter what.

  5. Anonymous

    How much work is involved in getting LÖVE to compile? Which version of Visual Studio? I have Visual Studio Express 2008 and Visual Studio Express 2010. If either of those will do, I am willing to take a look at it but can make no promises.

    Email is adrian2 at caribe dot net. Replace 'at' and 'dot' with corresponding characters.

  6. Anonymous

    After downloading the sources I can see that LÖVE is compiled using MinGW's build system, which I find a pain to use on projects other than those specifically designed to work with MinGW out of the box. Before I invest any more time into this, I need to know how much work is involved in getting all of LÖVE's dependencies to compile under MinGW.

    I could really use some sort of guide to compiling LÖVE under Windows. If those who maintain LÖVE's official Windows build could send me an email detailing their approach to compiling LÖVE under Windows, I'd be willing to invest some time into fixing this bug.

    Again, email is adrian2 at caribe dot net.

  7. Anonymous

    So far it looks like it might be a driver issue. The program crashes with "0xC0000005: Access violation" on the first call to glClear() inside Graphics::clear(), and the problem disappears once the latest ATI drivers are installed. The problem likely depends on the state of OpenGL at the time glClear() is called, as calling glClear() before "boot.lua" is run does not cause the program to crash.

    Having said that, I feel the bug should not be closed yet as it may be that installing the latest drivers is only hiding some problem specific to LÖVE that only manifests itself under particular circumstances. I'll therefore continue to investigate by looking at the various love::graphics::opengl::Graphics{} members as potential sources of error.

    - Adrian

  8. Anonymous

    I've discovered the reason glClear() wasn't failing prior to loading "boot.lua" is that the OpenGL window doesn't exist yet at that point. If I call glClear() immediately after SDL_SetVideoMode(), the program then crashes as usual. At this point it seems most likely it's either a driver issue or SDL issue rather than a bug in LÖVE.

  9. Log in to comment