I have a DNN 3.1.1 installation running on .net framework 1.1.4322.2300.  I have 2 portals running with internal and external url's and unique IP's. The external ports are firewalled and only pass traffic on port 80 & 443.  I have a 3rd site that i was developing on the same DNN host with an internal IP and URL (same IP # shared by all three) I tried to activate the new portal on the Internet and began getting Service Not Available errors or timeouts in the browser. All the other portals stopped working as well.

In the Even Viewer Application log I have the following error:

Event Type:    Error
Event Source:    .NET Runtime
Event Category:    None
Event ID:    0
Date:        5/12/2006
Time:        11:01:44 PM
User:        N/A
Computer:    XWeb
Description:
The description for Event ID ( 0 ) in Source ( .NET Runtime ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: .NET Runtime version 1.1.4322.2300- Setup Error: Failed to load resources from resource file
Please check your Setup.


I checked the worker process and they were stopped.  I moved my new app to a new worker process and was able to get the other Portals working again.

Chatter on the web indicated this could occur if permissions were incorrect or if there was a stack overflow caused by a recurssive process in a .net application.  Everything else was/is working and this app was working on the internal NIC for quite a while (6months or so).  Looking at it I would say that it's possible this was just a freak occurance (not the first time something unexpected and unrecoverable has happened on DNN for me) or that something has broken/puked when accessed from the highly firewalled public environment.

Is it possible that one of modules that I have purchased or downloaded is trying to make a call on a firewalled port and causing an overflow?  I've tried to catch anything like that with Sysinternals tcpmon app and haven't seen anything that would indicate that eventuality and I'd sure hate to think any of the DNN developers was engaged in spyware activities.  If you have any ideas about correcting this I would really appreciate it.

Regards,
Bob

I had this same problem and came to the same (bandaid?) conclusion - use seperate application pools.