On Tuesday, January 17, 2017 at 3:05:55 AM UTC-5, Andrew Marlow wrote: > > I think this is also what I am seeing. I have just started using cryptopp > version 565 in FIPS mode on Windows 7 with the Visual Studio 2015 update 3 > compiler. I have two apps that use crypytopp, one is just an ordinary app > and it works just fine, The other, the one that fails, is a wrapper for a > Java VM service. >
Java and .Net can be tricky. They load and unload the DLL multiple times during the app's lifecycle. The problem is, they don't re-initialize the library. The first load of the DLL gets initialized as expected, and then DLLmain is called. The environment unloads and DLLmain is called again with for unload. Then, when needed again, the library is loaded again. But this time, the library is in a bad state because the environment does not re-initialize the DLL. Static variables will be junk rather than 0-iniatlaized. The unusual loading/unloading from a managed language probably explains the -0xffffffff you are seeing. The pointers are not 0-initialized as expected, and a crash results because its really garbage. I believe your best bet is to ensure the DLL is not unloaded once loaded. Jeff -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cryptopp-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
