User2134761932 posted
Perhaps someone has some hint how to go from what we analysed so far - or maybe I'm wrong at all which may be even better!
We are using an automated test system to verify the functionality of our web application server. To do so the virtual directory configuration is updated quite often (we integrated our settings into the IIS7ff schema) and at first we saw a lot of the indicated
error entries in the system event log. For some time there should be no real harm of the entry but when we analysed indeterministic failure of our tests we found that those were working on out-dated IIS configuration. And this even if we check the configuration
out-of-band from the test and see the correct settings at the time of the failure!
After a bit of WinDbg and Process Monitor I think this is what happens - and I have no idea to come around of this failures without hard synchronisation in the test environment which we currently think will slow down test execution quite a bit:
when the IIS master configuration (applicationHost.config) is changed, the IISAdmin / WAS service (one process instance for both of it - at least on Win2008R2 - the error can be seen on Win2012R2 as well) creates copies of it (c:\inetpub\temp\apppools)
for each (active?) application pool. It then uses some file operations (Copy / Move) to propagate theses new versions to the indiviual sub directories for the application pools. Each worker process (w3wp.exe) will file watch its private configuration and reload
on such an update - to stay current on the configuration.
So if a configuration change occurs files will be copied and moved and the application pools will reload the personal copies by simple re-reading the file. If during this read the NEXT configuration change occures the IISAdmin / WAS service will try to go
to the next copy / move cycle which will fail since the file is still locked for read. And we are talking about the full configuration and so each change for each application pool may interfere with each other. The more pools the better a chance to get an
ACCESS DENIED.
Funny enough beside the entry in the event log the IISAdmin / WAS service seems (?) to take no further action. The new configuration is simply not copied and the application pool(s) may use out-dated copies of the overall configuration. Which may lead to
misbehaviour.
Although I think in production it would be hard (non-automated) to generate two separate (CommitChanges) configuration changes in a small time interval this is a potential race condition which may corrupt the state of the application pool and therefore all
virtual directories / applications hosted in it. Even if we could do some delay in our test enviroment - how long should it be? Eventually this depends on system load! And: all configurations must be serialized - bad for use having 4-8 tests running in parallel.
Any idea how to synchronize with this IIS internal configuration propagation mechanism whould be helpful!
Thanks
Jochen
