Messing with the file ownership is certainly not the way to go. While it will work on your machine, the inherent bug will still prevail on other people's PCs.
Check the locations of your files vs. the shown paths. Esp. "Program Files" can be tricky as there is virtual folder magic in there. Where do you get that path from? Does Löve provide it or do you build it yourself?
After all this time you actually completed it, big congrats to you.
Works fine here, however the key controls have the Input type delay. If you're using WM_KEYDOWN/WM_KEYUP to check for this, try using a bool array to remember if a key is pressed/released. In the main loop only check for the bool array (set pressed=true when WM_KEYDOWN, pressed=false when WM_KEYUP). This should get rid of the delay.
The usual approach to tile based games is having them in an array (and thus concrete locations). Now you take the location and size of your object and calculate the tiles below the corners. This obviously only works if you have tiles of the same size.
Usually a exception comes with a bit more of info (show all you've got). Is the debugger stopping in the c runtime? If so, there should be a comment or message near the break location indicating what went wrong.
Probably you accessed freed memory or wrote out of bounds somewhere.
Should you really be closing an application down with alt-f4 anyway?
If it's only happening from within visual studio then maybe the debugger simply doesn't like to quit by alt-f4? I'd recommend setting up maybe the Esc key to quit so your application can close gracefully.
Not a good idea to ignore the problem. Alt-F4 has the same effect as pressing the X on the top right. i.e. it's sending a WM_CLOSE to your WndProc. A lot of users use those ways to close a program.