A former employee implemented a custom VB.Net Context class that inherits DictionaryBase and implements ILogicalThreadAffinitive. The class object maintains values such as user ID, language, location, etc. throughout the user's session in an ASP.NET web application with .NET 4 Framework.
<Serializable()> _
Public NotInheritable Class Context
Inherits DictionaryBase
Implements ILogicalThreadAffinative
... Class Methods ...
End Class
The object class seems to work fine, holding the values as expected when navigating from page to page, even when loading a popup page. My issue arises anytime I have a PostBack action. When this occurs, the object becomes null and causes null reference errors.
The strange part is that it works for everyone except me. It's installed on our client's system, runs in our test environment, and works for our other developer on the project, but there's something preventing it from working in my development environment, which hosts the application with the local IIS 7.0 web server. The other developer and I have cross-checked all of the local IIS settings, VS2010 settings, and internet options that we would have altered, but everything appears to be identical between the two machines (both Win7 x64, building the application in x86 mode). Needless to say, this issue has become very prohibitive for development and troubleshooting issues.
Are there any suggestions as to what else can be checked that might produce such behavior?
EDIT: After some more advanced digging, it appears the PostBack is causing a request to fire on a second thread. This second thread, despite what documentation seems to say, does not carry over the values in the CallContext. On my colleague's working environment, this request is handled on the same thread. This seems to be the main symptom of the problem, but we still cannot pinpoint the source. Also, perhaps of note: my machine has an SSD and the other developer does not. I don't know if that affects threading, but I don't think it would produce these results.
I'm not particularly satisfied with the solution, but I was able to run the program without errors by switching to the ASP.NET v4 Classic Application Pool. As stated before, my colleague's machine is running the program just fine with the Integrated Application Pool. On my machine, however, this causes threading issues.
So, not a satisfactory "answer" per se; but I have a solution, nonetheless.
Related
In a hybrid asp.net web application, framework 4.5.1, using LINQ to SQL (not Entity Framework) I'm getting the exception
"An unhandled exception of type 'System.StackOverflowException' occurred in System.Data.Linq.dll"
on any call to DataContext.SubmitChanges().
Every call to SubmitChanges() causes the error, it does not matter what specific entity is being altered. The error is thrown immediately (unlike most StackOverflow exceptions, which normally take a few seconds to occur while the errant code overflows the stack).
The asp.net web application is running on my local host in IIS express using Visual Studio 2013. The database is SQL Server 2005.
My question is, how does one debug a StackOverflow exception in this environment? Right now the above error message is all I get.
The Event Viewer notes that the browser crashed (it happens in both IE 11 and Chrome) but nothing about the LINQ to SQL exception.
The SQL Server process monitor does not register any database call.
I have a log hooked up to my DataContext but it records nothing.
It appears the stack overflow is happening inside System.Data.dll before any database call occurs and before anything can be logged.
This suddenly started happening several hours ago, after a windows update ran and the machine rebooted. That might be a coincidence.
Something else extremely odd: we have four developers in our shop, all using Visual Studio 2013. Two of us suddenly began having this problem, and two of us never had it. We're all running identical code and hitting the same database. The two of us having the problem rebooted, and the problem disappeared on one machine, but is still occurring on my machine.
In addition to rebooting, I've deleted the project from machine and pulled it down from source control so that it is identical to what my 3 co-workers have, deleted all temporary internet files on my machine, and deleted all of my AppData\Local\temp files for my login.
Is there any way to debug this issue?
Clip of call stack when exception occurs (the calls to VisitExpression and etc repeat many dozens of times until it ends).
The unsatisfying "answer" in this case was to delete the *.dbml file and re-create it. That fixed the stack overflow error.
My comment in reply to #GertArnold above was not accurate. Only one DataContext was throwing the stack overflow exception. It was doing it for every entity in the DataContext, but other DataContexts in the application were working properly.
This particular *.dbml file has been growing over the years to gargantuan size. While re-creating I was careful to only add database objects that are being referenced, which resulted in a much smaller *.dbml file, which might itself have fixed the problem.
Thanks a lot Tom for the info!
Just in case other people may hit the same problem, here is extra info from my case. I have got a very similar issue after my PC got a batch of Windows updates yesterday, the updates including windows10 OS, VS2013/VS2015 and etc. I primarily use VS2013, some differences with Tom's case are,
it only pops up when update one entity, other entities in the same DataContext work fine
only affects my ASP.NET Web API project, console applications are fine, even all app projects ref to the same unitofwork data layer project (in where the dbml file sits)
replacing the dbml file didn't work for me, I finally solved it by opening the solution in VS2015 >> debugging >> closing VS2015 >> opening the solution in VS2013, the problem just disappeared
After moving all my solutions over to a newly installed machine (which makes me think this is a config issue), I am now having this problem with my MVC 5 web application(s).
When I build my web application (VS 2013), this of course regenerates all the web code and IIS will restart the application on next page load. However now it seems, when I go to my start/login page, the Application_Start() fires as expected, but when the page is submitted, before the HttpPost method is reached, the entire application seems to start again (Application_Start runs again). This second start seems to occur before the first Application_End() is called...but regardless of the sequence I have no idea why this is now an issue.
Checking the application shutdown reason in Application_End() I get the notorious vague (and apparently completely undocumented) "BuildManagerChange"...which MSDN gives some ridiculously vague description of.
Does anybody have idea why this would start after loading my development environment onto a new machine. Both machines are Win7 Pro running IIS7.5, and I believe the IIS config is identical to the old one (though, apparently not??). The source code/web.config/etc has not changed between machines.
The only documentation I could find on this issue was in regards to using IISExpress, however I am using the standard IIS7.5 installed with Win7 pro.
Edit: After removing all custom code from the entire startup of the site, and reverting my LoginController back to it's original simple form (no custom code), this still occurs.
Well, wasting 2 days on this was fun! But, this was resolved. Running procmon showed that hash.web was being accessed by mcshield.exe (McAfee AV). Apparently the live "on access scanner" checks the asp.net cache, and somehow IIS is aware of this and thinks it needs to rebuild the site again. For some reason McAfee does not check it after this first time so it functions normally after a second build/restart. I added a scanner exclusion to the c:\Windows\Microsoft.NET folder, and that seems to have solved the issue. –
A bit late to the party, but maybe it'll help someone. For me it was because I accidentally mapped two IIS sites to one directory. This resulted in two IIS background worker tasks and Application Application_Start() being called twice even though the second site was marked as "Stopped" in IIS.
We have created one .Net Assembly and made it accessible as COM object.When we are trying to expose any method of this object in ASP page we get an error "80131509". We are not getting any error when we are instantiating the Object. i.e. Server.CreateObject is passing through.
This is working fine in our development environment but we are getting this error in UAT environment. Development and UAT are almost same except UAT is more secure. I have tried all possible ways but no luck. I am working on this issue for past 4 days and any help will be appreciated.
I am suspecting there may be some permission issue with IIS 7 on exposing that dll. But not sure what it can be? We have given full rights to IUSR too.
Code :
set obj = Server.CreateObject("DataAccess")
dim rs
set rs=obj.GetLocations("All") <--- **Here i am getting an error.**
We have a few com dll's at my work and we often run into problems where we register the dll with regasm and the dll does not work. It works in other live environments but for some reason it just will not work in this one instance. Com dlls are fickle. Sometimes we will register it, unregister it, re-register it, and reboot. Sometimes they mysteriously start working other times not.
There are a couple more things that can go wrong.
Make sure that the correct permissions are set on the folders the dll lives in and on the dll itself. Also make sure that any dependent dlls are present and also have the correct permission. Ensure that everything the dll needs access to also has the correct permissions.
If that fails open regedit. Search for the guid associated with the com object. Sometimes you will discover that the paths the registry have are all mixed up. Clean out any references to the com object, reboot, and re-register it.
I have also seen an exception being thrown in the constructor causing issues. When the com object starts up it blows up. In one of our objects added a method to send an email when an exception occurs.
In one case we had an old com object that was no longer compatible with the version of windows we were running. If you have upgraded the server it is on that could be the problem. In our case we wrote our own component to replace the broken old one.
Also make sure that if the com object is strongly typed that you use the "regasm /tlb /codebase fickle_com_object.dll"
In short there are several things that cause com object to not work:
Multiple paths in the registry
Wrong security permissions on folders
Crashing when being created
Perhaps one of these things will solve your issue. I know how difficult it can be sometimes. Good luck!
I have three Silverlight 3 applications in the same solution. In my asp.net hosting project I have a seperate page for all three projects. When I navigate between the pages, the only Silverlight breakpoints that get hit are the ones the initial page I load.
This problem has only started recently. I used to be able to debug between all silverlight projects at the same time. Any ideas? I have deleted the ClientBin folder, I have deleted all files and re-retrieved from source control. Nothing seems to be working.
"The problem has only started recently". What changed? Here are some guesses:-
You upgraded to Windows 7
You installed some more memory
Some other memory guzzling app is no longer running when you are testing.
By default IE8 will run multiple processes at least 2. One for the browser frame and one for the content of the intial tab. As you open more windows and tabs IE may add new processes to the set it is currently using.
When you debug VS will launch an new IE8 session and will attach to the process handling the content of the single tab that is open, (it doesn't bother attaching to the parent frame process). However as you navigate about your application IE8 will start new process that VS won't be attached to. This forces you to open the Attach to Process dialog and do it manually.
You can control this IE8 feature (called BTW LCIE, Loosely Coupled IE) from the Registry.
In the Key HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main add a new DWORD value TabProcGrowth. Set its value to 1. Now IE8 will only ever create 2 processes per session one for the frame and one for all the tab and window contents which is the one the VS will attach to.
This perhaps is a bit draconian if you also use IE8 as your general browser. One option is to leave IE8 for test purposes and use another browser for general browsing. Another option is a variation of the above. Instead of creating TabProcGrowth as a DWORD create it as a string type instead and set is value to "small". In this mode IE8 is much less aggressive in the number of processes it will open. Of course you could create a couple of scripts to create and delete the registry entry.
Note without the registry entry IE8 uses its own hueristics that depends on available memory etc to determine if a new process is warrented or not. This might explain why in the past your debugging worked and that for apparently no reason it stopped working.
Here was the issue:
One of my child windows had a Silverlight that calling a .Net Ria Service. The service call ended in an error.
The next time several I debugged, the debugger did not attach to the child windows. I had to attach to the child windows manually.
I fixed the Ria Service call so that it did not end in an error. And had to manually attach to the child windows in that debugging session. However in subsequent debugging sessions, the debugger automatically attached.
I tried breaking the Ria Service call and I had to manually attache again. What is a little weird is that closing Visual Studio and even rebooting the machine does not make Visual Studio automatically attach again. You have to have a debugging session where the child window make a sucessful call to a Ria Service to fix it.
NOTE:
The RIA error that was breaking my debugger was caused by a misspelled include in the domain query (ie...
return Context.SOME_ENTITY.Include("Misspelled_Association_Property");
) not all RIA exceptions cause this problem.
My scenario has a number of specific cases that I will go over. I don't have all the things handy to test a more general scenario, but I will when I finish my project unless someone does this first.
Here is what I have:
I am using the a LinqToEntitiesDomainService from the July 2009 Preview release of .Net RIA Services.
To complicate things a little more, since my application is using an Oracle backend, I am using DevArt's dotConnect Entities provider as the EntityFramework model for my domain service.
When I get time, I will try this on the Nov 2009 RIA and a standard SQL backend and EF to see if I still have the same issue. If this is the case I will report it to Microsoft as a visual studio bug.
Trying to print an ASP.NET Charting control behind the scenes in my web app. I think it is a permissions issue with the printer as everything is ok up until the point where my code calls:
chart.Printing.Print(false);
bool finished = false;
while (!finished)
{
finished = File.Exists(settings.GetValue("statusfile")); // file which indicates document was printed
System.Threading.Thread.Sleep(1000);
}
At this point the page just freezes (or continues to load endlessly - infinite loop!) Understandably this is happening because I am 100% relying on the document being printed. I do intend to add a timeout, however, at the moment I am just trying to figure out why exactly the document is never being set to the printer!
I have given the account (which the AppPool is running under) permissions to all the relevant folders and even the pdf printer itself...Still nothing.
Am I missing something? Is there any issues with printing on the server side via ASP.NET? I have encountered some issues doing this via WindowsServices in the past not sure if it is a similar problem with ASP.NET websites.
Update
As suggested I updated the AppPool to give myself (admin) permissions and it is the same issue. So by the looks of things the job is never being sent to the printer. I can't seem to figure out why though...
Probably should have mentioned this in my original post....but I am invoking the printer through a referenced DLL, this code is not being called directly from my application (incase it matters). Also this runs fine on my Development machine which is running Windows 7 IIS7.0 where as the server is running Windows 2003 server with IIS6.0.
Update 2
I removed the while loop and just left in the chart.Printing.Print(false) line and turns out the document IS being sent to the printer. So the issue must be with the settings file not getting written which is why the loop never breaks out!
To isolate if this is indeed a permissions issue, you could try running the application using the Visual Studio web development server, which will run under your credentials. Or if that's not an option, temporarily change the IIS app pool so it uses your credentials. If things still do not work, you may have another issue. I'm not sure which charting library you're using (is it the newish Microsoft one?), but maybe Print wants to show a printer dialog.