I have inherited an ExtJS project that uses ASP.NET Web Handlers (ashx files) to access a database.
I'm trying to debug the connection to the database which is in the C# portion of the code.
I've tried adding a break point just before the connection to my database is made, but I can't seem to get the application to stop there. They only briefly turn white during debug-execution. Hovering the mouse over the breakpoint when it's in that state shows:
The breakpoint will not currently be hit. No symbols have been loaded for this document.
I've been all over this question, with no better results
In the modules window, the Symbol Status of the DLL does indeed show Symbols Loaded.
The dll/pdb both seem to be copied over to C:\Users\myid\AppData\LocalTempTemporary ASP.Net Files\etc.
(this seems odd, because I would expect it to attach to the .dll in my work folder) Is there a way to tell the debugger to look there instead?
There of course is no exe since this is a web app.
I've:
tried cleaning the solution and rebuilding fresh including a fresh pull from the repository.
verified the build has the "Define Debug Constant" and "Define Trace Constant" are checked
deleted the contents of Temporary ASP.NET
checked the the project was set as Debug
checked that "Just My Code" was disabled in Debug / General
restarted the workstation completely
checked that the Solution has the right project starting (there's only one in it)
checked I'm building in debug (not release)
made small changes to the code to force a recompile
checked that "Automatically determine the type of code to debug " is selected in Attach to Process
run as administrator
checked Optimize Code is not turned on in the project properties
checked that "Use Managed Compatibility Mode" is turned off
There is no aspx involved so the CodeBehind/CodeFile issue is moot.
Beyond that, that answers are very much repetitive or I tried something at random and it worked.
What have I missed? Is there something basic that you are supposed to do with the project so it will let you debug the DLL that perhaps the original developer didn't do (no they aren't available to me)?
Problem resolved...
Ultimately there were two issues.
Originally, the DLL had been compiled as 32bit DLL which didn't play nice with the database (Oracle 64bit). Switching the platform target should have resolved the issue except, IE's cache of the web page hid the fact that I was now getting a classic "Could not load file or assembly xxx or one of its dependencies." error. [incidentally, I've now sett he cache to clear on exit]
This error was caused by IIS Express running in the 32 bit version instead of the 64 bit version. Which means the DLL never really run, and explains the "No symbols have been loaded for this document." warning.
That was then resolved by going to Tools -> Options -> Projects and Solutions -> Web Projects and turning on Make sure that Use the 64 bit version of IIS Express for web sites and projects.
Clean and rebuild, and everything works tickety-boo
I have a COM component that I would like to use from Classic ASP. It is registered correctly using both the 64 and 32 bit version of regasm, using the /codebase switch.
All assemblies are signed with a strong name (although the key is not protected with a password). When I register the types, I get a confirmation that they were registered successfully.
If I make a VBScript file that attempts to create the COM component, it succeeds without issues when I run it with both the 64 and the 32 bit version of cscript.exe.
However, when I try to do a Server.CreateObject on the exact same COM component, I get the following error:
Server object error 'ASP 0177 : 80070002'
Server.CreateObject Failed
somefile.asp, line 2
80070002
The line provided by the excepton just contains the Server.CreateObject statement.
The assembly is AnyCPU, and the type I am trying to expose has a [ComVisible(true)] attribute set on it. The rest of the assembly is not COM visible.
Any clue on what I am experiencing here? I tried giving full permission to Everyone for the DLL files because I originally thought it was an IIS issue. However, that simply doesn't seem to be the case.
I have Googled this for many hours and seen countless similar questions, but this is not related, since none of the proposed solutions work.
If it works correctly with cscript.exe and failed in ASP, almost all the time that is due to the security context or file/register permission issue. ASP runs under the IIS user realm, and you will need to ensure that user ID has access to all the resources (including temp file/folder) needed for your COM object.
I solved it, but as I suspected, it wasn't the same cause as seen in other questions.
Apparently if you try to register a DLL from a network share, it will provide those symptoms, although the message is "Types registered successfully".
Very scary.
When moving all my DLLs to a local folder on the machine, they registered and ran successfully without issues.
After the last windows Security Update (Oct 17, 2014) my MVC 5 solution (System.Web.Mvc) started misbehaving. I'm using VisualStudio 2013. Thanks to the help I received in here I fixed the problem according to the instructions found on this page and that one.
However another problem has emerged. Everytime I debug my solution I got the following message:
C:\Program Files\IIS Express\ntdll.pdb: Cannot find or open the PDB file.
C:\Windows\System32\ntdll.pdb: Cannot find or open the PDB file.
I searched for the dll but I couldn't find it. In an attempt to solve the problem I emptied the Symbole cache and I reloaded all symbols from the Microsoft Symbol Servers in a new folder that I've created with read and write permissions. The problem remained.
In fact it's not an error because I can still run the solution by clicking on Continue and the website works well eventhough the ntdll.pdb is not found. How can I overcome this problem and how can I recover the ntdll.pdb?
Thanks
I think your solution resides here, which is the "Understanding symbol files and Visual Studio’s symbol settings" page. It describes how to configure VS's settings for using symbol files/where they're stored.
Additionally, you can acquire system PDB's for multiple versions of windows directly from MSDN, this is useful for remote debugging scenarios (production environments, or those with multiple host operating systems which need to be debugged.)
Ideally you would want to set up your own symbol store(s) and configure visual studio accordingly.
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 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\