Relatively new to working with .net but learning a lot while working with a developer at work who at times can be stubborn. Recently the asp.net web form we are developing has periodically started crashing such that every time a link is clicked that retrieves an object (an in process form that the user had previously filled out) the user gets the following application error: "Sequence contains more than one element."
All the sources I looked at online suggested that this was an InvalidOperationException thrown by the Single method and could be avoided by (a) eliminating the source of duplicate elements or (b) using the First method instead of the Single method.
The developer told me that I had no idea what I was talking about and that this was a caching error that could only be solved via an IIS reset.
Since this has been happening periodically I'm a bit concerned that doing the IIS reset doesn't address the underlying issue that creates the exception. Any one have any ideas? Is my developer right to say that an IIS reset is the best way to address this?
Thanks!
According to me your developer might have used LINQ. If he used single() or SingleOrDefault() or First() , tell him to replace those method with FirstorDefault() method.
Related
In a BizTalk mapping, I use a scripting functoid from an external assembly. The assembly reference is added. When the mapping is used, however, it causes the following error:
'ScriptNS0:DoSomething()' has failed.
Now, this could mean any number of things that's wrong about this scripting functoid. However, even when a try-catch block is placed around the entirety of the C# code and the catch throws a custom exception, a proper new deploy yields the very same error and not the newly added custom one.
This would suggest that the mapping has been started and that something causes an error as soon as it hits the scripting functoid, but without actually performing even the slightest action within the function. When looking at the XSLT of the map, it seemed perfectly fine. The reference to the external assembly has been checked over and over again (and references of this external assembly as well). Everything looks fine and very much like many other mappings I've seen, yet still the outcome is the error above.
I realise this is a rather vague question, but does anyone have a clue what's going on here?
You'll have to test this out in Visual Studio. A few things to keep in mind:
It's very possible that your actual data is causing an exception (it's an edge or corner case that you're not testing for in your console application).
Throwing exceptions in external assemblies doesn't always translate well in an XSLT map, particularly when you do it on a Port. IIRC it's handled slightly more gracefully in an orchestration.
If you can't reproduce this in Visual Studio testing or a unit test, you should be able to attach the Visual Studio debugger to the appropriate BtsNtSvc.exe or BtsNtSvc64.exe (or w3wp.exe if it's running in IIS/isolated host). Set a breakpoint on the entrance to your custom function, step through, see what's going on. If you're only able to reproduce it in a non-dev environment, see if you can set up remote debugging - but you may be better off enhancing the logging on the functoid in that case and redeploying if possible.
In general, I always try to do the following in custom functoid scripts:
Avoid throwing exceptions - use methods like TryParse rather than Parse, and on failure to parse return an error string or an empty string or the original string (depending on requirements/tolerance of destination system) rather than throwing an exception. If you do throw an exception, it's unlikely to be handled gracefully and unlikely that the exception type or text will make it back to a user/administrator.
Do error logging in these scenarios instead - generally using the Windows Event Log (System.Diagnostics.EventLog.WriteEntry). Make sure to use a properly registered event source, ideally one that matches your application name and is registered by your installation process, but at least one that exists on the computer to avoid throwing another nonsensical exception! This will allow developers/admins faster insight into what's going on next time.
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
I've got a weird problem using MVVM-Light in a WP8.1 universal app. When the download folder has been changed, I am sending out a message via Messenger that contains the new StorageFolder download folder.
I am registered to receive this message in two different viewmodel constructors (one for the main page, one for a custom file manager page). Instances of both have already been created.
When I run this in my emulator, everything works as it should. I get the message on both viewmodels. However, when I run this on my phone (Lumia 920 with developer preview), I only get the message on the main page, not the file manager page that even sends the message (from the page's own codebehind).
At a glance I'm wondering if there's a thread problem here due to the difference in speeds... but I also wonder if there's a bug on the ARM side of the MVVM-light toolkit.
Based on how I was using the MessengerInstance.Register method, I was the victim of a limitation of the Messenger system (not a bug exactly). Someone else described it here exactly:
https://mvvmlight.codeplex.com/workitem/7640
Basically, I was using a lambda that included a parameter from outside the lambda statement, making it a class held with a weak reference. This was garbage collected and then gone forever. Fixed by rewriting the entire thing...
I'm having a simple ASP.NET application hosted on my local IIS6, under Vista.
It contains a button that when I click I execute a piece of code for recognizing the text in a WAV file (using the System.Speach.Recognition.SpeechRecognition class) and display the text in a label.
The code works great on a desktop application, and it almost works on the web one... I say almost, because if I debug, I can see that the recognizer returns the correct text from the WAV, I can see that I am finishing the handler for the button click with no error, but nothing gets displayed in my page, and the page appears like loading... it's hanging, or something... No errors, no timeout, nothing. Just loading...
I don't know if this detail helps, but in order to make the piece of code that was already working on the desktop application work on the web application, I had to set the identity of the ApplicationPool of my application to LocalSystem (security breach, I know). Otherwise, I would have received a Access Denied error (0x80070005(E_ACCESSDENIED)).
Do you have any ideea why the call hangs like that? I'm fighting with this for more than two days, time pressures me, and I have no clue... Any help is really welcomed!
Thanks!
After another one week of stuglles, I found an overcome to the problem. I'm posting this just so other that might have this problem find the solution faster.
The solution was to call the method for making the speech recognition on a different thread. I think this forced the release of all resources in that thread after the recognition ended.
I cannot make any sense why this even happened on the first place (I used using blocks and I closed and disposed all the object in all the imagining ways), but I suspected to be a memory release problem...
Anyway, a very simple call on another thread fix it!
How many can relate do this?
Server Error in / Application
Object reference not set to an object
Description: Object reference not set to an object.
Exception Details: System.NullReferenceException: Object reference not set to an object.
Source Error:
Line 56: posts.Add(post);
On a more serious note, what are the first things you look for when you see the
yellow screen of death? Half the time the debug trace isn't actually telling you what the problem is (understandable I guess).
I must admit, I still use Response.Write more than I should. I just get lazy going through the debugger. What techniques do you use to debug the problem?
If I'm unable to identify/resolve the issue using the error message that the page presents to me, I will typically try to use the Windows Event Viewer to help me identify what is causing the issue.
For example, SharePoint errors are sometimes far less than descriptive. So, I'll combine what I'm seeing on the Y.S.O.D. with error messages from the Event Viewer to help me narrow down the cause.
I will do my best to ask a co-worker or other associate that I think might have some experience that might help. If I'm still unable to identify the cause, I will resort to Google armed with all the information.
Here's how I try to reduce the number of YSODs. One of the first things I do when starting work on an app is to create a custom exception class.
Add properties such as the SQL
statement being run. Two display
message text fields, one for display
to users, one for display to
developers (in debug mode) Who is
the logged-in user. Get all the form
variables so you know what they were
trying to enter.
Log the errors somewhere (event log
is good, if you can access the web
server; logging to the database is
less successful when so many
exceptions are inability to access
the database).
Create code in the MasterPage or web page base class Page Error events and Application Error events to do the logging.
Create a custom error page. When in
debug mode, the custom error page
displays everything. When not in
debug mode (production), display
only selected properties of the
custom exception.
Investing the time up front to do this will save you many hours of anguish later.
I usually do my debugging on my local machine with the Cassini web server (comes with VS 2005/2008). If I see an exception on my QA or, heaven forbid, my production box it's usually because I forgot to update my connection strings so that they point to the QA/production database instead of my local machine.
In other cases, I've found the stack traces to be very helpful in determining where to provide breakpoints so I step through it in the debugger and examine the data at runtime. The only time I've written any debugging information on the page was when trying to find some performance issues that I couldn't replicate on my developer instance. In this case I wrote some hidden fields that contained timing information about various parts of the render process.
the error info provided, assuming you are in debug mode, will give you information as to what line the error actually occurred on, along with the lines of code leading up to the error. This info should give you a good start on defining where to set your break points for debugging.
I was once in your shoes many moons ago, using response.write for debugging. Once you start using the IDE and debugger as it's intended you'll find yourself pulling out less hair and getting to the solutions much faster.
Also, opening up the immediate window while debugging is gonna make your life even more happy.
Use a decent logging framework such as log4net, and be liberal in your use of DEBUG-level logging.
It's essentially a neater version of your Response.Write approach, which can be left in your production code and "switched on" when required.