Does the level in question use a large variety of graphic sets? This, especially if it's one with a lot of images (ie: many animation frames and/or lots of terrain pieces; the size is irrelevant as far as I know, it's just the quantity that matters), and even more so if heavy use is made of flipped / rotated pieces (especially objects), can lead to such errors.
Note that making an Epic-style tileset will not avert this issue, as it isn't so much "how many graphic sets are used" that causes this, but more "how many total images are in all graphic sets this level uses, combined"? (If we want to be really technical, it will also keep in memory any graphic set used by the last four levels that were loaded in addition to the currently loaded one.)
While making the code more efficient in terms of how it handles images, or less efficient in terms of keeping pieces in memory in case they're used again, can reduce the impact of this bug - and I have some ideas on how to further do this - nothing short of heavy modifications to Graphics32 (so it doesn't use DIB handles in the first place) or outright replacing it, at least behind-the-scenes (while maybe still using it for loading image files and graphic output) will outright prevent it. It's an issue that I'd love to get fixed for once and for all, but that might be a while before it happens (with that being said, new-formats is inherently more resistant to this than the old-formats version is, because it doesn't have to load the entire graphic set, it only loads the pieces that are actually used by the level).
Changelogs for V10.13.17 and V10.13.18 don't suggest that I've made any changes that would reduce how likely this issue is to occur, but it may be worth testing with V10.13.18 anyway, on the offchance I made improvements but forgot to note it in the changelog. V10.13.18 will be the final version of NeoLemmix until the new-formats version is ready, I'm not even doing hotfixes at this stage.