Geek Answers Handbook

Explain this obscure ASP.NET error

I just pushed the site to production, which worked fine in the QA environment. The patch included DLL dependency updates and some database scripts.

I will move on to the persecution and explain the mistake that took me 4 hours to understand. One of my database scripts created a stored procedure that was not [dbo] before its name. Therefore, instead of becoming [dbo]. [MyProcedure], he became [shawn]. [MyProcedure]. When the script was executed from code through the System.Data.SqlClient library, it killed the entire ASP.NET workflow. This caused the application to restart and redirect back to the login screen. The procedure was called conditionally and rather rarely, so it is difficult to reproduce.

Since he pulled out the entire ASP.NET workflow, it was very difficult to debug. I did not have the opportunity to catch a mistake. In the end, I noticed this in the Windows event log:

Exception: System.Runtime.Serialization.SerializationException Message: Unable to find assembly 'Shawn.Core, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null'.

(Note: the root namespace has been renamed to protect the innocent.)

And then, after 2 seconds:

 EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.3959, P3 45d6968e, P4 mscorlib, P5 2.0.0.0, P6 4889dc80, P7 4687, P8 4b, P9 shawn.data.dataaccess, P10 NIL.

At this point, I realized that it was an inconsistent version of the assembly, a GAC conflict? or something similar. I checked every link in my entire project and tried many different things. In the end, I looked for all the references to the Shawn.Data.DataAccess namespace and wrote to the file every few lines to find where the application fails. This led me to the right stored procedure.

TLDR : why the lack of [dbo] on one script causes the whole ASP.NET workflow to crash?

+4
source share
2 answers

It crashed because your data access functions could not find the stored procedure, and when you called it, well, since the stored procedure could not be found, the runtime threw an unhandled exception.

As for killing the entire ASP.NET workflow, this is because you had an unhandled exception. The process could not recover from the exception because it was not processed (there is no attempt / catch around your reading, etc.), therefore the only thing it can do is restart the process.

As for why [dbo] compared to [shawn] causes a crash ... well, this is due to the ownership of objects in SQL Server. Users can access any object owned by DBO without specifying the owner, but if the object belongs to an account that is NOT a DBO, then you must provide the full name. (ie. [shawn] .myStoredProcedure). More details here: http://www.sqlteam.com/article/understanding-the-difference-between-owners-and-schemas-in-sql-server .

+3
source

You have to do something unusual to bring down the workflow. This has nothing to do with the database error - it should be related to where this error occurs in your code, probably in the background thread, but even then ASP.NET usually protects itself from being crashed with excluded exceptions.

It’s best to always surround all code with any methods that are executed in threads using try-catch.

0
source

More articles:


All Articles