I am reading an .opml file and parsing it to generate a list of articles for each rss feed I subscribe to and thus add into this .opml file.
At times, when pressing play on Visual Studio (Run), I get an error (not exception) stating an OutOfMemoryException. This is before the application can even run (but has compiled). The page in question (the error comes in the output window with the relevant page) is the RSS Reader page, which calls the methods to do the parsing.
How can I completely fix this error? This error only comes up at times so it is hard to reproduce. Some information points to an issue with my dev environment, not the site or Visual Studio (This could mean another set of variables when live). Has this exception got any link to a potential memory leak (is it a possible warning)? Would memory profiling help (I have a memory profiler)?
Thanks
If I understand correctly, Visual Studio itself is OOM and reporting that it cannot start the debugg process. Is the devenv.exe process using a lot of memory? If you are under VS 2005 on a 64 bit OS you can try the advice from this post to make the devenv.exe use 4GB and perhaps aleviate your problem.
If is not VS itself that is OOM, you'll need to locate the problem. The culprit should be the one that shows up in task list with a large VM size. Running VS itself under debugger may help. Also, sometime system errors (like kernel resource exhaustion) are translated to OOM error.
How are you parsing this? You can run out of memory in a variety of ways, such as doing this in a tight loop:
for(....)
{
//Creates immutable strings faster than they can be garbage collected
nextXMLPart = nextXMLPart + " " + something;
}
How big is the file? If you are reading the entire file into memory that would do it.
Any how, I'd start looking at any loops that repeat a lot. And if that doesn't work, fire up task man and put break points in the code. Watch for where the app is when memory usage starts to shoot up.
Related
I'm trying to do a ping to a server in a Windows Forms Application but when my program is running, I have memory dump on my computer. Very, very strange.
In my method I only have:
private void CheckServer()
{
this.txResponse.Text = "";
IPAddress IpAdress = IPAddress.Parse("anAdress");
Ping ping = new Ping();
PingReply pingToReply = ping.Send(IpAdress);
if (pingToReply.Status == IPStatus.Success)
txResponse.Text = pingToReply.Status.ToString();
}
I really don't understand what is going on.
I'm using Visual Studio 2012 with .NET Framework 4.5 on Windows 8.If it is necessary more information, please let me know.
Verify that the parsing of the IP Address is successful; otherwise check the surrounding processing outside of the CheckServer method.
Ahhh, the joys of programming having a program blow up when there is absolutely nothing wrong with the code... (your code looks fine other than putting a try/catch block around it)
It could be a hardware issue (memory, disk etc), bad dll, or any number of things that go bump in the night. I assume you have tried rebooting your computer, and pinging your server at the DOS prompt. If not do so.
One thing you could try is to call ping.exe directly with a command line/ip of your choice synchronously or asynchronously, see http://www.codeproject.com/Articles/25983/How-to-Execute-a-Command-in-C and then parse the output to get what you need (lines starting with "Reply from" or "Request timed out." or even the % loss line.
Another thing to try is bypass the c# Ping and PingReply calls entirely and use net sockets and a timer, see http://sourceforge.net/projects/pingutil/?source=typ_redirect particularly the ping.cs file.
These solutions would allow you to potentially write around the problem, but it does not necessarily solve the problem at hand, which does not appear to programming related from the code you have provided.
OK, other thoughts... 1)Do a rebuild all on your project 2) Try compiling using an older version of .NET 3) Create a new project and copy block the source into the newly created files. 4) run the project on another computer to see if you get the same results. Any exception error that may or may not be generated should never cause a core dump.
Yet another option is to analyze the core dump, for an application, see: http://sourceforge.net/projects/core-analyzer/ and also check out
Tool for analyzing java core dump
Worse comes to worse, you may have to reload Visual Studio and/or .NET.
Currently I'm programming an application to record data. The data will be stored clustered to a file.
This data can be analyzed by the user or the program displaying the data. By analyzing large amount of data the program ends suddenly, i.e. there is no exception, any other error message or any process at the task manager just no more program.
By analyzing the program with perfmon I found lots of i/o (460 events/s and 15MB/s) at this moment as expected. Is there any limit reading data from different places of a file? (I'm seeking positions and read complete clusters.)
Make sure you're wrapping your code with a try..catch. Then set a break point in the catch. (#Paolo makes a good point, be sure the try..catch is in the thread that is doing the work.)
Also, you could try setting visual studio to break on all exceptions. "Debug" / "Exceptions" / Select relevant "Thrown" check boxes.
Also, try checking the Event Viewer for some hints.
Finally, you can also do Debug.WriteLine or Trace.WriteLine in certain places (esp if running on a system w/o visual studio) and monitor output with Sysinternals DebugView
Note: Be sure to make code production qual (i.e., add logging, program defensively, etc) after/while finding the source of the issue.
Use try..catch.
Subscribe to AppDomain.CurrentDomain.UnhandledExceptions.
Use NLog.
Watch the process' working set.
I need to get a crash dump from a program. How do i get it?
The Program is written in C#. What exactly is a crash dump? When is it created? Where is it saved?
How do i read it?
Since you are saying C# I assume you are using the Windows platform.
A crashdump, or just dump, is the complete memory snapshot and other related system info of a process at a particular point in time. Dumps can be used to debug program crashes, hangs, memory and resource leaks and probably more problems I have not listed here.
In the case of crashes and hangs the first piece of data you want to obtain from a crash dump will be the callstack. This indicates the point of a crash or the point at which an operation blocked and never returned so the program sits and does nothing.
For resource leaks multiple memory dumps of a process can be collected over a period of time and examined to see which objects in memory are growing the most. This can help narrow down which parts of the code are causing the leak. To learn more about debugging specific issues I highly recommend this blog.
There are a few ways to capture a dump file.
Procdump (http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx)
Visual Studio 2010 (http://msdn.microsoft.com/en-us/library/vstudio/fk551230(v=vs.100).aspx)
WinDbg - Not to bad but more intimidating than other tools
With procdump you can simply do:
c:\>procdump.exe -ma YourProcessName.exe
The result of this command will be a full memory snapshot of YourProcessName.dmp written to c:\ . The -ma switch specifies dumping a complete memory image. If you are debugging a crash or hang you can likely get away without the -ma switch. Keep in mind without the full memory dump when you go to examine data structures you probably won't have valid data. Without the full memory dump you will still have callstack data which is often good enough for crashes and hangs. I typically error on the side of harddrive space is cheap so collect the full dump.
Procdump will also automatically take dumps at time intervals or when a specific condition is met. Read the documentation at the link above for more info. One switch I would recommend is -e.
c:\>procdump.exe -ma -e YourProcessName.exe
Instead of writing the dump immediately it will only write it when your program crashes.
With Visual Studio 2010 you can attach to the process with the debugger and save a dump file. (Keep in mind when you F5 debug your program Visual Studio automatically attaches). When your program is in a "break state" (breakpoint, unhandled exception, crash) the Debug menu will have the option to Save Dump As.... Then you can save that dump any where you would like.
Since you mentioned C# you are very likely collecting managed dump files. The easiest way is to use Visual Studio 2010. Simply, open up the dump file you created as you would any other file and begin debugging.
However, if that is not an option you can always use VS2008 or WinDbg with the SOS extensions. I do highly recommend Visual Studio 2010 though as SOS extensions and WinDbg in general have a pretty steep learning curve. To learn more about SOS check out these MSDN articles here and here.
Another reason I recommend using Visual Studio or procdump is that they will collect the dump file you expect. I recommend steering clear of Task Manager's "Create Dump File Tool". The reason being it will collect 64bit dumps of 32bit processes which are overly difficult to debug.
On Windows XP you can create a dump file with this utility:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=e089ca41-6a87-40c8-bf69-28ac08570b7e&displaylang=en
Once installed browse to the installation directory and run
userdump PID
from the command line where PID is the PID of the process you want to get a crash dump of (you can find this in task manager, but you might need to add the column to the standard view).
This file can then be opened in Visual Studio - you just need to make sure you have the symbols built.
In Windows 7 just right click on the process in Task Manager and select "Create Dump File"
Use ADPlus. It comes with the Debugging Tools for Windows.
It'll create folders of crash dumps beneath it's home directory. You can analyse them using WinDbg afterwards.
Luke, a crash dump is a whole bag of data related to the status of your application at the moment the crash has happened, to dump it means to record all those information somewhere, typically in a text file.
a basic approach is to log the whole stacktrace when an exception happens so you could investigate later and see what method has failed and thrown which exception, what the parameter values were and so on. This is not really a crush dump but helps a lot in many cases.
There was something developed recently by MS about crash dumps and application crashes, I think it was related to Windows 7 actually...
see here: Application Recovery and Restart
http://msdn.microsoft.com/en-us/library/cc948909(v=vs.85).aspx
You can also try using WinDbg
http://www.windbg.org/
A crash dump is when the contents of RAM memory and certain parts of the processor are copied to a file. This file is created at the critical point of an error and can be used to debug the problem.
This has worked for me in the past. It's a keyboard shortcut to crash dump in windows.
* Start Registry Editor.
* Locate the following registry subkey:
o HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\i8042prt\Parameters
* On the Edit menu, click Add Value, and then add the following registry entry:
o Name: CrashOnCtrlScroll
Data Type: REG_DWORD
Value: 1
* Exit Registry Editor and then restart the computer.
http://vinaytechs.blogspot.com/2010/01/how-to-get-crash-or-hang-dump.html
I developed an benchmark-style console application (C# 4.0). Worked fine with 50,000 or 1,000,000 iterations. Then I increased a iteration count to 50,000,000. But it took too much time, and I forced it to quit. The application quitted normally, but in my main drive (C:) remained only 3.8 GB available. Before the testing free space was 14 GB. There's 10 GB has been ate !!! Please, can anybody explain why this happened?
Hi All,
I found that *.vsp file on my project directory (9 GB !!!). Yes, it may seem to be silly, because I looked up for every system|hidden folder on my main drive, but never I thought this giant file may be in my project folder. After the 50,000,000 iterations, I felt that my system got slower, and I ran Performance Wizard in VS2010. But iteration count was very little, so I did not think that performance wizard can create such a giant file! Thanks to all!
Without more information (like what the test actually does) my guess is that the program leaked memory like a sieve, and Windows compensated by steadily increasing the size of the swap/paging file, eating up your hard disk space in the process. You might take a look at your C:\pagefile.sys and see how big it is.
For the why - it could depend on your string operations (for example performing concatenation vs. using StringBuilder).
As for where the space is, as stated before it's likely to be your page file.
If it is your page file, the way to reclaim the space is to manually adjust the size of the page file to a much lower than current value via Windows and then reboot.
Windows key + Pause/Break, click Advanced System Settings, under Performance, click Settings...
In the resulting Performance Options window, under Virtual memory, click Change... Tell Windows to stop automatically managing paging file size. Click on C: drive and set it to a custom size significantly smaller than it is now (try 1024MB for example).
Reboot your machine and the pagefile should now be smaller. Until you restart, the space will still be in use.
You'll probably want to set the paging file size back to being automatically managed by Windows once done.
If you'd like some help in avoiding the code causing the same problem, you might need to provide some code snippets.
I guess that's because virtual memory swap page increased, because GC was not running in your iteration loop and the memory usage increasing and then eventually memory got swapped to page file. See http://support.microsoft.com/kb/828988 for more information about GC in console application. I never tried that but I think using MTAThread attribute would help.
Temporary Files of Swap Space (Virtual Memory).
Does your app create files? How much memory does it use (Task manager)?
An app I'm writing always crashes on a clients computer, but I don't get an exception description, or a stack trace.
The only thing I get is a crash report that windows wants to send to Microsoft.
I would like to get that dump file and investigate it myself, but I cannot find it.
When I "View the contents of the error report" I can see the different memory dumps, but I cannot copy it or save it.
You can use the Windows debugging tools to view the crash dump. To get the most use out of it, you'll need an exact copy of the symbols for that application (i.e. same version).
Have a look at Tess's blog for tutorials on how to use the Windows debugging tools. I refer to her blog constantly whenever I'm in need of analysing crash dumps.
Tess' blog was a great resource. Eventually I managed to figure out how to do remote debugging which means I didn't have to look at the crash dump.
For the general community, here are some links I found useful:
Remote debugging, how to set up and run it.
Crash dumps, how to save and debug them.