I am trying to trace a possible memory leak in a very large ASP.NET application. I am trying to familiarize myself with WinDBG before attempting to use this tool in the live environment.
I have followed the instructions in the following article, which I found very helpful: http://humblecoder.co.uk/uncategorized/spotting-a-memory-leak-with-windbg-in-net. I am able to create a "memory dump" file of the ASP.NET process and show that the delegate is causing the memory leak as specified in the article. I refer to the paragraph in the article that starts: "Next we need the symbols". I did not add the symbol files using File\Symbol File Path; in WinDBG and yet I still seem to be able to debug the application and follow through the remaining steps of the article. Are symbol paths not required with an ASP.NET application?
Because .NET assemblies contain metadata, including the name of every method and its parameters, symbols aren't necessary to obtain a readable stack trace of a managed thread.
One thing symbols can provide is the file name and line number of each statement, so you can more easily figure out which frames in the stack trace correspond to which lines in your source code.
As Michael says symbols are not strictly necessary for managed code as most of the relevant information is available at runtime as metadata, but if you're digging into native code it is very useful to have symbols.
For many scenarios you can just do .symfix which will tell WinDbg to use Microsoft's public symbol server. That will give you access to symbols for all the CLR and Win32 specific calls in your code. Remember to do a .reload if you set the path.
If your code includes native non-Microsoft assemblies as well, you need to append the location of the corresponding PDB files to the symbol path. Use the .sympath command for that.
To troubleshoot symbol loading use the !sym noisy command.
For more information see this.
Related
Is it documented somewhere how ASP.Net sets up search paths for native DLLs? I need to be able to replicate the logic in my own code.
For more background: I'm maintaining a managed library (say Managed.DLL) that wraps a native library (say Native.DLL) that in turn uses another native DLL (say Driver.DLL). So far Managed.DLL has been importing functions from Native.DLL using .Net's DllImport attribute, but now I have to change this to hand-coded calls to LoadLibrary and GetProcAddress to get more control; in particular, I need to be able to call FreeLibrary to unload Native.DLL and I can't do this when Native.DLL has been loaded via DllImport.
And here comes the problem: While just DllImport("Native.DLL") is sufficient to locate both Native.DLL and Driver.DLL, calling LoadLibrary("Native.DLL") fails with ERROR_FILE_NOT_FOUND when Managed.DLL is used in an ASP.Net application, because the directory containing Managed.DLL is not on the search path for native code DLLs.
My first thought was to use Assembly.GetExecutingAssembly().Location and then issue the LoadLibrary call with a full path, but then Native.DLL fails to find Driver.DLL, because the directory containing them both is still not on the search path.
I could work around this by using the Assembly.GetExecutingAssembly().Location value to set the native DLL search path with SetDllDirectory, but this has two major drawbacks:
1) SetDllDirectory changes global WinAPI settings and could interfere with other code within the same ASP.Net worker process that also uses native code DLLs; I have also verified that using DllImport attribute does not mess with this setting, so changing it now could indeed break something that was working before.
2) It would still not work for debugging ASP.Net applications from within Visual Studio, because VS copies the managed resources into a temporary directory, but leaves the native DLLs in the project build directory, so they end up in different locations in the debugging session (and the temporary directory is wiped for every debugging session, so copying the native DLLs into it manually does not work either; I had to copy the native DLLs into IIS's directory for the debugging session to find them and this is clearly not acceptable solution).
I really would like to do the compatible thing here, but so far haven't been able to find out what this is and after couple of days of fruitless searches any pointers would be greatly appreciated.
To answer my own question:
1) The keyword I was missing regarding the copying of Managed.DLL was "shadow copying" (James Schubert explains it much better than any official Microsoft documentation I've seen) and the trick is to use Assembly.CodeBase instead of Assembly.Location, because the former gives the the original location of Managed.DLL and the latter the location of the shadow copy (John Sibly and Sneal shared nice code snippets to extract the directory name from the URI in Assembly.CodeBase).
2) The way to make dependencies of the native DLLs available is to explicitly load them using LoadLibrary before they are needed (and since this increments their reference counts, also release them with FreeLibrary when done).
So, the loading sequence is
string dir = Assembly.GetExecutingAssembly().CodeBase;
dir = new Uri(dir).LocalPath;
dir = Path.GetDirectoryName(dir);
IntPtr driver = LoadLibrary(dir + Path.DirectorySeparatorChar + "Driver.DLL");
IntPtr managed = LoadLibrary(dir + Path.DirectorySeparatorChar + "Managed.DLL");
and the unloading sequence
FreeLibrary(managed);
FreeLibrary(driver);
(note also the order of LoadLibrary and FreeLibrary calls).
When using HP-UX I can use the chatr utility to report on various internal attributes of a shared library. It will also allow me to modify the internal attributes of shared libraries that I have built.
The chatr utility can report, and in some cases modify, such things as:
the run-time binding behaviour,
the embedded library path list created at build time,
whether the library is subject to run-time path lookup,
internal names,
etc., etc.
Is such a utility available for Solaris?
Edit: Freaky! Thanks to mark4o's answer below I revisited the elfdump output for a typical system .so (libm.so.2 on Sol 10). However, and here's the freaky part, I mistyped the command to enter:
elfdump libm.so.2 | moe
In an amazing stroke of serendipity, this gave me back the usage message for a utility called moe whose man page description section says:
The moe utility manifests the optimal expansion of a path-name containing reserved runtime linker tokens. These tokens can be used to define dependencies, filtees and runpaths within dynamic objects. The expansion of these tokens at runtime, provides a flexible mechanism for selecting objects and search paths that perform best on this machine.
This will help me resolve why a libm.so.2 shlib is not compatible on both of two different machines leaving my incomplete executable unable to start on one server.
For displaying the information, see the Solaris elfdump and pvs utilities. For debugging binding issues, lari and moe may also be helpful. However, these utilities do not have the ability to modify the library.
Starting with Solaris 11 (and some of the OpenSolaris & Solaris Express releases leading up to it, but not Solaris 10 or older), there is now an elfedit tool for modifying runtime paths and similar attributes.
I am having an issue when attempting to override the DisplayNameAttribute in ASP.NET MVC to provide a localized string. The code itself is straightforward and similar to that in another Stackoverflow post link text
The code works for global resources but not so well for local resources. I have a registration screen and used the Visual Studio "Generate Local Resource" command to create my local resource file. The generated file is named Registration.aspx.resx and the App_LocalResources folder is created relative to the actual Registration.aspx page - as one would expect.
However, when I attempt to get the localized string using:
ResourceManager.GetString(resourceKey)
I receive the following error message.
Could not find any resources
appropriate for the specified culture
or the neutral culture. Make sure
"FullAssemblyName.Views.Account.App_LocalResources.Registration_aspx.resources"
was correctly embedded or linked into
assembly "FullAssemblyName" at compile
time, or that all the satellite
assemblies required are loadable and
fully signed.
Using reflector, I can see that the file is actually Registration.aspx.resources and not Registration_aspx.resources - the underscore/period being the subtle difference
FullAssemblyName.Views.Account.App_LocalResources.Registration.aspx.resources
I have toyed with the code quite a bit but no matter what I do, the file being requested is always different than that copiled in the assembly. For instance, if i rename Registration_aspx (in the generated Registration.aspx.designer.cs class i get the same error but this time the path is "...App_LocalResources.Registrationaspx.resources"
Has anyone run into this? Is there any way I can ensure that the resource found in my assembly has this underscore?!?!?
Thank you in advance!
Try Michael K. Campbell solution link text. It worked fine form me in localizing my project.
When ngen is executed on a .NET managed application at installation time, and a crash dump is retrieved from Windows Error Reporting for the app, how can you use it to see a stack trace, variables, etc.?
Here's some background related to the question: We have a .NET app that gets ngened at installation. When it crashes due to an unhandled .NET exception, the crash is bucketted in Windows Error Reporting, and from that I was able to download the minidump.mdmp file from winqual.microsoft.com.
I put minidump.mdmp in a folder containing the .dbg files for the build of the app that crashed, and double-clicked minidump.mdmp to open it in a new instance of VS2008 SP1. My stack trace looks like this:
kernel32.dll!RaiseException() + 0x3d bytes
mscorwks.dll!RaiseTheExceptionInternalOnly() + 0x295 bytes
mscorwks.dll!JIT_Throw() + 0x130 bytes
MyApp.ni.exe!000007feee74c84c()
[Frames below may be incorrect and/or missing, no symbols loaded for MyApp.ni.exe]
0000000070000d5e()
MyApp.ni.exe!000007feee611000()
000000000300bf78()
000000000300bf60()
The Modules window indicates that symbols are loaded for the OS and .NET DLLs, but for the application modules, I get this:
MyApp.exe -> No native symbols in symbol file.
MyApp.ni.exe -> No matching binary found.
MyAppsLibrary.ni.dll -> No matching binary found.
The easiest way to debug those dumps is with the Windows Debuggers (Windbg, cdb, or ntsd) and to load the SOS debugger extension (you can search for SOS for more details).
As far as I remember, the NGEN'ed part of thing shouldn't matter for SOS as long as you have the original EXE and the symbols (Since it's your app, I'd expect you have the non ngen'ed exe and symbols).
"Debugging Tools for Windows" (specifically, WinDBG) has limited support for managed apps. Provided with PDBs, you should be able to see the call stack, including source line references. To see variable values, you'll need to use the SOS plugin, which is more difficult that just opening the call stack window.
If you're able to request the clients to run your app again, ask them to run it with the following environment variable set: COMPLUS_ZapDisable=1
This way CLR won't load the native images when running your app and you'll see your usual modules with symbols on the stack.
http://referencesource.microsoft.com/faq.aspx
Is this of any help for you:
Symbol issue when debugging C# code
The guy seems to be able to load some symbols to debug his application from the crash dump, had a problem loading the correct symbols but someone answered his question.
Since this is managed code, you may need to set the _NT_EXECUTABLE_IMAGE_PATH environment variable to point to the folders where your executables live. In this case, you'll need to locate the folder in the NativeImage cache that points to your assemblies. The debugger needs the images in order to load the assembly.
I'm using selenium to run some functional tests on the UI for our current application.
I want to ensure that strings from the resource files in the Web project are being displayed at the correct time and place.
Simple (I thought) all I have to do is reference the assembly of the web application and assert that the text selenium is reading from the UI matches the test in the approriate resource file.
The problem is the ASP.Net does some precomilation processing on the resource files and compiles them into an assembly called App_GlobalResources, which isn't created by the normal build process so the functional tests fail because that can't find the App_GlobalResources assembly to look the string up from.
So, any suggestions? Do I need to abandon the App_GlobalResources approach and do something manual that I have control over?
Do you understand the problem or do I need to provide more info?
My interim solution is to use SVN:Externals to pull a copy of the resx files into the test project.
I can then access them via
ResourceManager resource = new System.Resources.ResourceManager("My.Web.Namespace.resources.ImageUrls", Assembly.GetExecutingAssembly());
Its ugly because I already have a reference to the webproject (which I can probably remove now...) and I don't like mixing source files between projects. It just feels like asking for trouble but until someone suggests something better this will have to do.
Have you considered moving your GlobalResources into a separate assembly and then referencing that from both your web project and your test project? This is quite easy to do in VS 2008, and achievable but a little more difficult in VS 2005.
I was able to solve a similar problem using that approach.