Hi you try solutions from this topic?
https://www.nopcommerce.com/boards/t/49851/serious-iis-application-pool-recycling-bugdesign-flaw.aspx
Yes... basically the root cause is that for some unknown reason, file permissions are ignored (at random) when copying the dll's from the plugins director to the bin directory. It doesn't seem to have anything to do with unsafe vs. safe dll's, etc.
In all our 4.0 and 4.1 deployments, we suppress the shadow copy. Anytime we need to put a plugin update in now, we copy the dlls both to the plugin and the plugin/bin folder and we have just removed all the shadow copy code.
Looking back at this issue, I don't even think it's a nopCommerce problem given that the failure occurs using the System.IO namespace. (eg. for 4.0 installations it fails in PluginManager when trying to delete the current file - File.Delete(shadowCopiedPlug.FullName); on a application pool reset. Given that, it feels like this is more of a .net / OS type error - not nopCommerce.
The average failure rate before we made changes was measured to be about 20%. So on a normal IIS application pool recycle, there is an 80% chance the line will not fail, but of course when the 20% chance comes up, only a manual app pool recycle brings the site back from its 500 state.
I am curious if anyone is seeing this in Win 2016 IIS / IIS 10 environment.