ASP.NET 3.5 and KB2533623, KB2507938 - asp.net

If I install either KB2533623 or KB2507938 on a Win 7 or a Win 2008, it kills my ASP.NET 3.5 application. The actual error I receive when loading the project is :
Invalid access to memory location. (Exception from HRESULT: 0x800703E6).
I don't have the full stack trace, but the error is coming from the LoadAllAssembliesFromAppDomainBinDirectory() call. Now the MS updates have made modifications to the way "insecure libraries" are loaded. My guess is that is causing me the problem. Removing these 2 updates will resolve the problem. It's not a machine specific problem, because this has happened on a total of 6 machines across 2 operating systems and managed by 3 different groups (so not just a bad image or something).
Assuming I need to secure my libraries, are we talking about just signing them? And if a 3rd party library is not signed, what then? Is there a way to tell ASP.NET to accept the libraries?
MSDN article http://msdn.microsoft.com/en-us/library/ff919712(VS.85).aspx talks about setting directories to load from. If this will resolve the issue, can I implement this before ASP.NET attempts to load all of the libraries from the bin folder?

Tony, I am not sure if following is the solution for you, but I don't have enough reps to put in a comment.
So some questions and suggestions:
1. On the front end do you get a HTTP 500 error?
2. Are these dlls in the bin folder of the web app?
If answer to any of above is yes, try this 'hack' -> Right click on the bin folder in Explorer and give [System]\Users access to the folder (where system is the name of the machine). First try with readonly, then try read write.
Normally your admin will baulk at doing this on production site. So someone will have to tell us how to 'actually' fix the issue.
You could also try the solution for the user running the AppPool.
I have had 500 errors with Ajaxcontroltoolkit.dll in bin folder and this is how I have resolved it.
Hope this helps.

Related

Problem with built assembly not matching source when debugging under IIS 7.5

I have a problem debugging a web forms application that is configured to use IIS for debugging, under Windows 7 and Visual Studio 2010. An example has just occurred, where I make a change to the code behind for a web form, save, and apparently rebuild before starting the app using F5.
The app starts, and I get an error message trying to do something in the app. I tell the debugger to break when an exception is thrown and try my task again, only to be told
The source file is different from when the module was built.
where the module is C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\9d7b45ca\11a98b19\assembly\dl3\5e6cf0b2\636409d4_dfeecb01\PerfixEMS_Admin.DLL
The physical folder for my test web site is set to the web application project's source folder, so I have always assumed that IIS will look in the bin folder for required assemblies, and these will be rebuilt as expected. Why is this not happening?
Cleaning the solution usually works for me.
Update
Given the high number (320) of projects I understand why Clean and Build won't work for you. You should however try it at least once to see if fixes things.
If it does fix your problem but doesn't last you'll need to do one of two things.
Clean just the one file
Delete the offending temp file. You probably won't be able to do this because with VS running since it may have a lock on the DLL. You may also have to stop IIS. You can use Process Explorer to look for the processes that have a lock.
Use a custom solution
Its unlikely that you're going to be modifing all 320 projects at the same time. Create a custom solution for just the projects you're working on. You'll still be able to step through any project you have the DLL and PDB for if you need to.
Which to do
Using a custom solution has its problems since you can no longer use project reference for projects not in your solution. This impacts your team's source control. You'll also have to make sure the DLL's and PDB's from outside your solution are in a stable location and you'll need a way to detect when thoes other projects have changes that you care about.
These problems can be overcome with a careful check-in process for Project changes and scripts that copy files and working with team members to figure out how to communicate changes.
On the other hand closing VS for every change or running Clean and build isn't really tennable either.
it may be a workaround, but I just need to see if it will work or not, then we may investigate more in the original case. but for now, try this:
1- publish this website to a different folder
2- open the newly published version from your preferred browser (ex: http://localhost/APP_NAME).
3- from VS, open "Debug" menu, choose "Attach to process..."
4- select the IIS worker process "w3wp.exe" and click "Attach".
(if you can't find it, make sure that the checkbox "show processes in all sessions" is checked)
5- start debugging your source code normally and let me know what happened, thanks.

ASP.NET web application can't find an assembly

I deployed an ASP.NET web application last night and I when I woke up this morning it was very slow and would occasionally just throw a 'Service Unavailable' error.
I checked the Event Viewer and it was filled up with these errors:
An unhandled exception occurred and the process was terminated.
Exception: System.Runtime.Serialization.SerializationException
Message: Unable to find assembly 'MonoTorrent, Version=0.80.0.0, Culture=neutral, PublicKeyToken=null'
I'm puzzled as it was working perfectly when I deployed it (MonoTorrent is required to retrieve the number of seeders/leechers for a certain torrent off the tracker - this was working fine), but it's no longer working and whenever code that uses MonoTorrent gets involved, the worker process just crashes.
MonoTorrent.dll is in the /bin/ directory.
UPDATE 6/4/10: I compiled the MonoTorrent source code in with the rest of my web application, but it still crashes whenever it uses MonoTorrent. However, it now says that it is Unable to find assembly 'OpenPeer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. Here, OpenPeer is the name of the web application's assembly.
This can happen in these circumstances:
The ASP.NET app creates a background thread, which throws an uncaught exception. It looks like ASP.NET catches the exception and wants to log it to the Event Log. To do this, it sends this exception from the Web app's app domain to its own app domain (the default one of the w3wp process). This needs a serialization/deserialization of the exception.
If the exception is a custom one (i.e. defined by the Web app), it cannot be deserialized in the main app domain of ASP.NET because the assembly defining the exception is typically in the Web app's bin directory, not where w3wp.exe is (c:\windows\system32\inetsrv). This causes a serialization exception and w3wp crashes.
There are possible ways to fix the issue (in a - very subjective - order of preference):
Copy the missing DLL in c:\windows\system32\inetsrv
Install the missing DLL in the GAC
Remove the cause of the exception (harder to do than to say, as we say in French)
Catch all exceptions from the background thread yourself and do the logging yourself.
Notes:
If WCF is used and the uncaught exception is FaultException, WCF swallows it and there is no crash
If the uncaught exception is in the thread of the Web request, there is a yellow screen of death, not this serialization exception
It really seems like a bug in ASP.NET
The above is actually a summary of my investigations of this issue yesterday and are only a theory. I tested fixes 1 and 4, as well as using FaultException.
Here are some things you can try..
1.) Flush ASP.Net Temp directory. Restart IIS and recycle Application pool.
2.) Make sure your web-application is running in FULL-TRUST if it really needs FULL-TRUST.
3.) Take the Assembly, try to use it in other asp.net application and run the test application on a seperate server. This might help you diagnose the problem. Also try to run the test asp.net app on the same server but in seperate application pool.
4.) Make sure the IIS website of your application is running under the user account with necessary security priviliges. Try running the application under Administratotr as user.
EDIT-1
5.) Also check if the assembly version is the same as mentioned in web.config. If there's a version mismatch then you can do AssemblyBinding Redirection in web.config.
6.) Also try registaering the Assembly in GAC and see if it loads properly.
EDIT-2
7.) Try reconfigring ASP.NET support on the server or maybe framework runtime re-setup may help. This may not be a sure-shot solution but looking at the problem condition we may want to try various solutions.
8.) Make sure you're not missing any critical update of your windows server platform.
I try to give you some ideas - what I do if I was on your position.
First of all I take a long look of the MonoTorrent.dll before some days that you make your question, and I look it again today. I found and the function that load the dll. My first opinion is that something have to do with the permissions.
I hope that you have access to the server - right ?
My first steps is that:
Ensure that your monotorrent.dll actuall have the right permissions to the bin directory, for Read, and execute by your asp.net app. Some times the copy of one dll, did not get the directory permissions buts carriage out his own permissions. To check if your dll have different permissions from the rest, just right click and see Properties | Security, then go to bin directory and do the same, and compare the Security permissions. If they are different then apply again the Directory permissions and make sure that the dll inherited by the directory.
My second step
Download the ProcessMonitor from sysinternals
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Run ProcessMonitor and try to recreate the error, stop it and analyse to see where and why the dll gets the denied permissions to run.
With the ProcessMonitor you can even see if there is any dll that can not found !
I have check the MonoTorrent dlls and I do not found anything unusual. He have kerner32.dll calls, and use unsafe code to run, ok nothing so special about.
So if you do that 2 steps and give me some feedback, maybe I can go further. (if not solve by you and what you find)
I would advice to setup Regular maintanence probably once in a week at sunday night etc for following,
Delete all temporary files
Delete all ASP.NET IIS temporary files
Restart Server
Problem is, ASP.NET web apps cause lot of temp files to be left in the disk, because of dynamic compilation of regex, seriliazation assemblies etc, such temp stuff never gets deleted, and more and more junk starts getting collected in temp locations, ASP.NET goes slower and slower, and a point comes in where disk as well as memory defragmentation reaches very high point, things start to fail.
No body likes to restart server once a week, but I remember we had no choice, in ASP.NET 1.1 we had stable system after restarting every day, in ASP.NET 2.0 onwards, we are good to have restarting scheduled at once a week.
I have found this problem and I have do all of thing as I can, such as clear temp file, restart server, delete and add reference and I also rebuild the solution. However I can't solving this problem. Finally I move my entity class (almost of them need to serialize) to new folder that I have added to the project and then this problem solved.
This method is work for me.
Try clearing the ASP.NET temp files. It's solved some odd issues before for me.
Otherwise, Fusion-logging may shed some light.
UPDATE: #Charlie - I'm not sure what to make of those logs...it looks like the failed log is from a different AppDomain. Notice the AppBase is set to "file:///c:/windows/system32/inetsrv/" and AppName is w3wp.exe.
I'm pretty sure the Event Viewer should show Application Id: LM/W3SVC/#/ROOT if it was the default AppDomain, too. At this point, all I've got is random guesses.
I notice you're running x64...does MonoTorrent perhaps require x86?
Have you double checked that the directory is an IIS application, and is configured for the correct version of ASP.NET?
Is there some other application that uses MonoTorrent on this server? Maybe a WCF service or something? I'm not sure where the Serialization is happening....
Try hooking the AssemblyResolve event and loading it manually.
Can you repro on a development machine? If not, maybe it's a borked FX install. Uninstall and reinstall.
Does restarting, recycling or stopping/starting the AppPool fix the issue temporarily, or cause the issue to appear?
You may want to type out your screenshot text too so you'll get some Google love....
Is the server timezone different than your timezone? I've had this issue when deploying resource files, the compile time was in the future so they would fail to load.
My guess that you have plenty of open but not closed connections. I mean the connections are not returned to the pool. It looks okay, when you start the application, but after some time there are only several sockets available in the pool and it goes slow. Another thing - non-closed connection may keep DLL in memory, not allowing to release the handler. Try to debug object destruction.
I know it's simple but I had this problem once and itwas because I had a Web Application project which contains
References
Folder and I just copied my files into a
Bin
folder, in any .net web application in the Project Properties windows, a Reference Path tab is available which by default should nothing be include on it. check this option and also Build tab in Project Properties window which Output path be as the same as bin\

DotNetNuke 3.0.x on SQLServer 2005/Net 2.0.Win2003 - possible?

I've promised to take a look at an old DotNetNuke installation for a client with the intention of making a few, hopefully minor, changes. The installation is rather old - I believe version 3.0.013 - and the production copy is running against SQL Server 2000, Windows 2003 and .Net 1.1.
As the production server is live and significantly used we need a development installation first. I have attempted to install a copy on my local server - Windows 2003, SQL Server 2005, .Net 2.0, and although with a few tweaks I can successfully get it to display the site, I cannot login, or even access the login module (ie just putting in blank username and password attempting to generate a 'must enter username' type error) without getting the error 'Object reference not set to an instance of an object'
I've spent some time trying to get around this error, without success, although I am hampered by not having used this package before.
So my questions are
Has anyone managed to run DotNetNuke 3.0.x with this configuration (or do I need to setup a box with SQL 2000 and .Net 1.0 to get it to run)?
Any suggestions where I should start looking for this error, or has anyone come across anything similar before?
EDIT: Eventually chickened out and installed in on an old webserver with Win2003/SQL 2000/Net 1.1 and it went in fine on an identical install. So I guess the answer is no, it doesn't work straight out of the box.
My feeling is that you shouldn't have any trouble running in the above mentioned environment. But taking a closer look at the error itself will help us to prove that.
If the error is occurring only when you navigate to the Login module, it may be an issue loading the authentication provider. The best way to find out is to look in the DNN Event Log and take a look at the full error message.
Because you can't login to access the Event Log, you should probably just take a look at the row created in the database when you receive the error. The table is called EventLog and there may be a little bit of friction in parsing the error message out, as all of the details are stored in the database in an XML format.
In general, when moving a site from one environment to another there are only a couple of things that you'd need to do:
make sure you can connect to the database
set the file system permissions
It sounds like you already have database connectivity because you can load the site.
However, you may want to double check (just re-apply) the file system permissions for the root of the website on the machine in question. Make sure the identity of the website (typically ASP.NET Machine Account or Network Service) has 'Modify' permissions on the root website directory. Perhaps the web site can't load a particular assembly due to lack of permissions.

Preventing UNC Share error at build time

At work we have a bunch of sites hosted on our development server. The folder containing all these sites is mapped as a network drive.
In VisualStudio I open the root of the site as a WebSite and when I build the site I alwys get this error.
Error 4 An error occurred loading a configuration file: Failed to start monitoring changes to
'I:\Sitename\wwwroot\' because the
network BIOS command limit has been
reached. For more information on this
error, please refer to Microsoft
knowledge base article 810886. Hosting
on a UNC share is not supported for
the Windows XP
Platform. I:\Sitename\wwwroot\web.config
I've checked out the KB article and made the registry changes it suggests but this didn't help.
Does anyone know of a fix or workaround for this?
Thanks
Instead of using a mapped drive, use full UNC path and give your current logged in user access to that path: \\MachineName\Sitename\wwwroot\web.config
Chances are high you will get a different effect from that , especially if the Mapped drive was being mapped with different credentials.
Take a look at this hotfix: http://support.microsoft.com/kb/911272
It cures the problem
Changing the FCNMode using that hotfix doesn't always fix the problem.
I made a very detailed answer to this problem here: https://stackoverflow.com/a/20710473/705198
That answer is an accumulation of all the technet, msdn, and blog reference material I could find on the subject, and what we ended up having to do to fix the problem. Disabling Jumbo Frames (HP Server NIC problems causing another error) and SMB2+ combined with the registry edits were what ended up saving us with our high traffic IIS sites. The registry edits alone only made it so the network bios limit errors would not show up as fast under normal load.

stopping app_offline.htm from being created and deleted at each build?

I have a solution with 2 projects in Visual Studio 2008 SP1, .NET Framework 3.5 SP1.
a ASP Web site.
a Class Library (dll) project.
I have a reference from the Web Site to the Class Library, as the Class Library is my data layer. But anyway, the thing happens only with this basic setup, a solution with these 2 types of projects and a reference from the Web Site to the Class Library.
Now, each time I modify something in the Class Library and I build it, Visual Studio creates a file called app_offline.htm and then deletes it (it sends it to the Recycle Bin).
This is really annoying because at the end of the day I end up with a full Recycle Bin and me, being the perfectionist I am, I want to keep it clean. I'm not the only one with this problem: here and here.
I know now the cause of the problem, but still not how to fix it. If you didn't hear about app_offline.htm before, here's ScottGu's article on app_offline.:
Does anyone know a solution to the problem? Some setting in VS to delete the file forever after the Build process? (I really don't want to set my Recycle Bin to do that, as I do delete things unintentionally from time to time and I'd like to be able to recover those.)
This file does not go into the Recycle Bin for me. Perhaps you have some draconian utilities installed, which do this? Many anti-virus tools and general system utility suites used to do this back in 2000 but I do not have experience with later versions.
Update: You can use Process monitor to find out which process moves this file to the recycle bin.
[Disclaimer: I'm adding an answer firstly because I hope it will get the question seen by more people (I admit it) and secondly because I have no characters limit on an answer, as oposed to a comment.]
I followed Sander's suggestion and used Process Monitor to track which process moves this file to the Recycle Bin.
It was indeed devenv.exe.
There are several events where it makes operations like: QueryDirectory, QueryOpen, CreateFile and CloseFile. And devenv.exe is the only process that has anything to do with app_offline.htm
Still... How could I make Visual Studio stop filing up my Recycle Bin? (way to go, Dan, putting a question in the 'answer' (: )
I started seeing the same problem shortly after we suffered a VSTS server problem. The VSTS server went down for a day so I had to open the solution in offline mode. After the VSTS server came back online, I had to reopen the solution under source control, and the app_offline.htm files start occurring non-stop every time I recompile my web projects.
THIS IS REALLY ANNOYING!
I am not sure how to stop it yet, but I know how to reliably recreate the problem on my environment:
Windows XP Pro, VS2008, SourceGear (Source Control System).
Whenever I perform a checkout, the app_offline.htm file is instantly created and deleted in/from the root folder. The source control system is using SQL Enterprise, so I am not sure it is related to some references from posts people are making about SQL Express.
Again, still don't know how to stop it, but maybe this will help other figure out how/when the file is generated and deleted.
Use Web Application projects, not the Web Site templates, those are for 'dummies'. :)
I had this problem because I published directly to Azure Web Service from the dev machine.
The answer here with another possible workaround here.
This is all I could find on the subject. Unfortunately it's also speculation.
http://petermcg.wordpress.com/2008/05/12/silverlight-app-offline/

Resources