App Pool Recycle in IIS is changing file permissions on a DLL

I've never seen anything like this and was hoping someone could point me in the right direction.

I have an app in IIS, and inside the bin folder I have a copy of Microsoft.Practices.EnterpriseLibrary.Common.dll.

When someone recycles the app pool or turns the website off and on again, the functionality of my application that uses Microsoft.Practices.EnterpriseLibrary.Common.dll starts throwing:

Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Access is denied.

The DLL in question, sitting in the bin folder, does have full control given to the service account given to the app pool.

To "fix" this, I've found I can simply perform any write operation within the same bin folder - rename a folder, delete a file, rename any file. They all do something that, without changing the permissions (because I've compared them before and after) resolves the issue.

If I recycle the app pool again, the same Access is denied error returns.

So my questions are:

What could be causing the Access is denied issue to begin with? Is the application not using the DLL in the bin folder that I'm expecting?
What does recycling the app pool do to cause the DLL to revert to an Access is denied state? Is it pulling in an old/cached/broken version of the DLL from somewhere?
Why does performing a file write operation in the bin folder fix this? What might IIS be doing behind-the-scenes when it monitors a change to the directory it is serving an application out of?

Solution

So after this problem persisted to other environments, I needed to quickly resolve this issue.

John Wu's answer helped me track down the problem to the temporary IIS folders that IIS was spinning up, where the first new folder fresh from an IIS reset was broken, subsequent forced new temporary folders worked, but overtime those would be "corrupted".

Guessing that perhaps a virus scanner or other scheduled process on the computer (which is shared among many teams and many applications unfortunately) was picking the file up and locking it, I tried moving my temporary folder elsewhere by adding this to my web.config:

<compilation tempDirectory="D:\Inetpub\[path to my application in IIS]\Temporary Files">

Temporary Files is just the name I gave a new folder within my applications deployment location. After giving my AppPool service account permissions to this folder, my problems went away.

I didn't solve the problem of what was messing with my DLL, but I've come to accept that, being on a busy shared box, it might be unavoidable - and simply moved my applications temporary files out of the common default location and into a new app-specific location.

App Pool recycles stopped breaking my app, and it's been working all morning. If you have this issue and can't spend the time to figure out what is locking your files, moving them out into their own location might help.