Late-Night Debugging: When Every Portal Went Down
Last night was one of those nights every software engineer person remembers.
At around 10:30 PM, all our portals suddenly went down — completely.

The screen filled with this scary message:
“Server Error in ‘/’ Application — Could not load file or assembly ‘Microsoft.CodeDom.Providers.DotNetCompilerPlatform’. Access is denied.”
At first, I thought it was a missing DLL issue. But everything was exactly where it should be. That’s when it hit me — this was a permissions disaster waiting to be solved.

The Investigation
No one in the team had a clue why this happened — it had never occurred before.
Later I found out it was caused by some user permission settings done on the server that unintentionally stripped access from our Application Pool identities.
Basically, IIS couldn’t read, compile, or serve anything.
The entire system was down — and the pressure was on.

The Turning Point
From 10:30 PM till 2:00 AM, I kept investigating, checking access rights, logs, and IIS settings.
After hours of frustration, I finally struck gold — the life-saving commands that restored everything:

icacls “C:\inetpub\wwwroot\<YourSite>” /grant “IIS AppPool\<AppPoolName>:(OI)(CI)F” /T
icacls “C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files” /grant “IIS_IUSRS:(OI)(CI)F” /T
iisreset

And like magic — one by one, every portal came back online.
The Relief (and a Little Bit of Glory)
By 2 AM, everything was back to normal.
No errors. No downtime. Just a huge sigh of relief.

That night, I unintentionally became the hero of the night — and learned one big lesson:
Never underestimate a few lines of icacls!
Thanks Allah for the save — and respect to every developer who’s ever fought a late-night production fire