Error 225 When Loading DLL Compiled on This Computer

Question

Brief background and intent: Building a small high-precision math library for use in a special-purpose scripting language under development
Recently completed a revision of the 64-bit DLL library's assembly source to improve performance of existing 128-bit division routines. Now when I load the library from any executable I get Windows
Error 225 (ERROR_VIRUS_INFECTED). Furthermore, Windows 7 is deleting the files
without notice at every call to LoadLibrary at the path. I can rebuild the file, but I cannot copy it out of its project folder using Explorer because it somehow
immediately deletes copies without warning (I kid not), though cmd copy works.
At prior versions the file had previously loaded successfully when built from earlier source. Now I cannot even test the file as a DLL without removing the new code sections.
I have of course scanned the file with Avast, and it checks out. Object and library even disassemble and show components as expected.
So is Windows doing some manner of static analysis of my executable? If so, what patterns in my design might be causing the false positives? Admittedly, there's a bit of spaghetti within the 600 bytes that make up the new division section, but I've
seen far more grievous sins load up just fine. I can provide [ugly] source if it's deemed useful.
Relevant System Details:
Operating System:
Windows 7 Home Premium SP1, 64 bit
Associated Tools:
Assembler: NASM version 2.11.05
Linker: LINK version 12.00.30501.0
LINK command line:
link /DLL /ENTRY:DllMain /OUT:BigTypes.dll BigTypes.obj
...Yes, I run very minimal when I've the option to do so.

Answer 1

Before sending the issue to the development forum I performed some further investigation regarding what characteristics of a DLL will cause Windows 7 to refuse to load it due to a false positive on virus identification.
Technical explanation: Any time routines share a common exit point that is not declared as 'export' for the purposes of the DLL, the Windows loader could raise the red flag if the jump crosses another exported label that the loader does
not understand to be part of the the body of the routine. This would cause critical components of a program to fail to load, likely without notice to the user.
Seems to be a well-intended but poorly-conceived security feature of the Windows 7 loader.
Potential consequences: As evidenced by my example, Windows also deletes the suspect file - also completely bypassing the recycle bin, and without warning -
so for most users the error would be unrecoverable even with a system restore.
Conclusion: Not sure if this is a Windows 7-specific issue or if this is a 'feature' of all versions of Windows. Had I a 64-bit machine running any other OS version I would be happy to test it. This makes me wonder specifically if early
64-bit Windows XP loaders would behave similarly; and if not, this could help explain why some users report anonymous failures of certain programs to load with Vista and upward, or even after some updates to XP.
Once I have time to create a more formal report I plan on submitting it to whomever at Microsoft is best equipped to address or in the very least
document the behavior so both end-users and developers alike are aware of why application components are failing.