This is the second time I run in this strange situation:

My application has a memory problem (e.g. writing over the end of an array) and crashes. While looking for the error I add plenty of prints and test the application several times, with several consecutive crashes, which is normal. Then, suddenly, my application doesn't crash anymore, but runs much slower.

It took me very long to realize that Windows does something with the folder that contains my application, since renaming it, and running the application again, makes it crash again as expected.

It is like windows detected that a given executable is problematic and then marks its containing folder as "run slower and more tolerant mode". I am not sure if I made myself understood, but I find that behaviour very strange, and couldn't find any other way to "unmark" the folder than renaming it.

Any explanation of what is going on is very welcome!

An additional detail about my application: it's a exe that loads and runs routines in a dll (the dll is faulty)

Windows does not do such things. Memory errors cause random errors, including no errors. Thus crashing, running slower, running normally, throwing BSOD, finding cure for cancer are expected behaviors of a program with memory errors.

3 hours ago, codingJoe said:

It is like windows detected that a given executable is problematic and then marks its containing folder as "run slower and more tolerant mode".

I don't have an explanation myself but I don't think any OS would or should attempt to repair faulty code in any why shape or form. I've seen many situations where this seems to have happened, but typically the failures comes back in the end, perhaps in a different way. If you have a bug you can repeat consistently, you typically have to just debug it and find the exact for it.  One of my rules is that I never fix a bug without understanding what the source of the problem was and why it's now fixed.  Stuff that just vanishes makes me nervous.

 Also if you found the array overflow were you able to fix it?  And why are you using a faulty dll? Can you fix it? Is it yours?

Under some circumstances Windows will "helpfully" catch exceptions that are thrown in message handlers.

https://stackoverflow.com/questions/2622200/exceptions-silently-caught-by-windows-how-to-handle-manually

https://stackoverflow.com/questions/23603391/why-does-windows-swallow-exceptions-during-wm-close

https://web.archive.org/web/20170214101142/http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/

https://randomascii.wordpress.com/2012/07/05/when-even-crashing-doesnt-work/

Memory faults causing different behaviour on different runs is to be expected for all but the most trivial of applications.

When you write past the end of an array you write over whatever was after it in memory. If this object is on the stack then it will usually be the same object that gets overwritten. If it is on the heap it may be an unused bit of heap, in which case it may not cause a problem, or it might be an other allocated object which will then be corrupted. If the latter, you might overwrite it with what was already there, with an invalid value that causes another part of the program to crash or a valid value that wasn't the one that was there before which can be really hard to debug. You may even overwrite an internal heap data structure, and everything might appear OK until you try to allocate or free memory to the heap.

Beyond that there are techniques such as address space layout randomization that can cause other variations of behaviour resulting from memory corruptions.

As others have said, learn how to identify where the problem is occurring. Even just running your application under the debugger so it stops you at the line of code the problem occurred at and you have all your data structures available so you can check that they contain what you expect them to contain is a useful start.