We have an ASP.NET web service (net 2.0/3.5) which after a couple of weeks of use gives a message
"System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.IO.FileNotFoundException: Could not find file 'c:\windows\Temp\xxxxxx.dll'"
where the filename xxxxxx.dll is a random string which changes on every occurence of the problem.
Once the error happens, even the 'iisreset' command does not fix the problem. A server re-boot fix the issue for couple of weeks. But then it comes again.
I have seen a lot of links where temporary file storage is the problem as a result of XmlSerializer dynamic compilation. Our Web Service code consumes Java web service, other than that, there is no explicit usage of XmlSerializer class.
Any ideas/advice?
Thanks in advance!
This blog post definitely solved the problem that we were facing (This will describe the problem we were facing). - http://devatheart.azurewebsites.net/2011/04/18/troubleshooting-xmlserializer-failure/
We had this piece of code
System.Diagnostics.Process.Start(RetrievedURL);
which was generating IE processes (Since IE was the default browser on the webserver) in the background on the button click and opening webpage.
Not a smart thing to have but we removed that code and it has definitely stopped the IE processes in the background.
How it is linked to XML Serialization Failure is explained in the above post.
Thanks for the research and this blog post Slobodan Stipic, a.k.a. Slobo.
Hope this solution helps others in future.
Try granting full permissions to this folder to the account you are using to run your application under.
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
I have a custom http proxy that one worked. I have made some changes to its authentication process. And now when I try to launch an applet I get "Incompatible magic value 1012089682 in class file ...". Regular html files are transferred without any errors.
In my other web research I found this article http://arstechnica.com/civis/viewtopic.php?t=313827 discussing an ascii vs binary transfer issue.
My problem with debugging this is that the get of the jar file doesn't show up in tamper data on the browser nor in the access log of the webserver containing the proxy, nor in my proxy error log. So I am some what baffled. any help in how to get more information to solve this would be appreciated.
The technology is antique, but the company doesn't want to pay for upgrades. The proxy is an NSAPI plugin running in IWS 6 (SunOne webserver)
Thank you.
There was indeed a bug in my proxy code. I am not exactly sure what caused the symptoms described above, but fixing the code so that it didn't re-authenticate every time fixed my issue.
I'm fairly new to web service development, and I am really confused about how ASP.Net Development Server synchronizes with code during debug mode. When I make changes to my service, I cannot figure out how to propigate those changes so that my client can "see" them (I've been able to synchronize through a stumbling series of publishing the service, viewing the service in browser, etc... but I have a feeling there's a more reliable system than my random ritual).
Here are the symptoms I'm seeing: After I've made a change to the code behind my service (Service1.svc.cs), started the application through the debugger and attached the debugger to the WebDev.WebServer.exe process as well, my latest changes are not executed, and my breakpoints are not hit (they have the message that
"The source code is different from the original version."
What really baffles me, though, is that when the ASP.Net Development Server notification pops up in my system tray, its physical path points to my project folder, so I don't understand how it could be looking at anything but my current code files.
I do not like to play with knives but the only thing that worked for me involves editing the .csproj file itself. So, unload the project file, edit it by cutting and pasting the three asp.net files so that they are together in the ItemGroup. However, sometimes it is necessary to go further as explained here: http://carnotaurus.tumblr.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same - Also, I give a list of other proposed solutions that did not work for me. I hope it helps.
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!
I have one web application. while i debug the solution the rendering makes too slow and if i close the browser page i got one error like this
WebDev.WebServer.exe has encountered a problem and needs to close. We are sorry for the inconvenience.
I got one information from attched proess is that this .exe file related to asp.net development server- port(port number).
How it can be resolved? please help me..
You cannot close the browser that opens when you are running debug for an ASP.NET program.
It renders slower because you are debugging it. This means the compiler has injected a lot of extra code need to make the application work with the debugger. There is no getting around this.