>Just thought that in case something can reset oApp.lInitialize - for whatever reason - the first test may think it's initialized and when it executes the next line it isn't anymore

That might be the case as the locking code, once done, sets oApp.lInitialize to True. So, the other instances of the same worker process, once they receive their go ahead lock, will go in it but will get out immediately by the use of the inside second oApp.lInitialize verification.

And, we want the first oApp.lInitialize verification to remain there, the outer one, as we wouldn't want each hit after that, such as a quarter millions hits a day, to use SyncLock for nothing.