We are excited to announce that the IIS.NET Forums are moving to the new Microsoft Q&A experience. Learn more >

WAS Event Log Entry 5189 with Event Type '7'RSS

2 replies

Last post Dec 09, 2014 01:17 AM by JMS-1

  • WAS Event Log Entry 5189 with Event Type '7'

    Dec 08, 2014 02:56 PM|JMS-1|LINK

    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

  • Re: WAS Event Log Entry 5189 with Event Type '7'

    Dec 08, 2014 10:11 PM|lextm|LINK

    You have entered a road that no outsiders can help you much. Make sure you open a support case via http://support.microsoft.com and directly discuss with Microsoft guys who have access to the code base. Only via that channel you might get some meaningful assistance.

    Lex Li
    Want to have a chat on the issues you meet? Book an appointment at https://buy.stripe.com/cN24ia0yi7sAdIA7sv
    ---------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights.
  • Re: WAS Event Log Entry 5189 with Event Type '7'

    Dec 09, 2014 01:17 AM|JMS-1|LINK

    Actually I came here exactly for the inverse reason: based on previous experience over quite a couple of years I think neither support nor connect will be of any help and THIS here is THE IIS pro forum with microsoft involved. At least many people around here are using IIS for a long time and may have found some work-around.

    Anyhow - thanks

    Jochen