I have found multiple ways of creating dump file such using windows utitlity userdump and adplus.vbs and a few others.
There is one option that I have found in task manager seems to be the easiest and simplest one open task manager + select the process + right click + create user dump. Is the .dmp file created using taks manager any different than the one created using win utilities?
Getting a user to create a dump file from task manager is so much easier than having him run the utilities.
Keep in mind that on a 64-bit OS, the dump created by Task Manager for a WOW process will be a 64-bit dump. This can cause problems, especially if you're debugging managed code. For 32-bit WOW processes, it's generally best to use a 32-bit utility.
Not sure what the difference is in the minidump created from task manager but if you want further information then the best thing to do is to create the minidump either programmatically and set the appropriate flags (note that some flags are OS dependent) or using Dr. Watson where you can simply check the boxes for the information you want in the dump file.
You can programmatically create the dump using MiniDumpWriteDump: http://msdn.microsoft.com/en-us/library/windows/desktop/ms680360%28v=vs.85%29.aspx there is a SO article on this: How to create minidump for my process when it crashes?
You can also setup dr. Watson to generate them for you when the crash happens:
http://kb.acronis.com/content/2191
the task manager solution is fine but generating them automatically is better IMO and generating them programmatically gives you better control and the option to dump additional information specific to your app.
One of the methods that we use for catching crashes or hangs on end-user machines is with the excellent ProcDump utility, and we write a simple batch script that either sits and waits until the app is unresponsive, or you can set other conditions such as when the CPU usage reaches a particular point. I give an example in this response.
Related
Is there a way to monitor the state of a console application?
I am trying to build a user interface which shows whether or not a console application is currently running on the server (processing files). If it is running, I would like to show the current state: how many files processed, what file currently being processed, etc.
The only way that I can think of doing this:
Create a text/xml file when application is started
Update text file with information about current state for each object it processes
Delete text file when the application is finished processing
To me, this doesn't seem like a very good or efficient way to do it. Is there a way to detect if the ClickOnce application is running, and perhaps some other way to access the "Messages" or Log of it to show the progress?
Note - I am also looking into using NodeJS to do this, but unsure if it has this capability.
First, you should consider writing this as a Windows service instead of a console application.
That said, scraping a log file that your application is writing is a reasonable approach. Just ensure that it never gets too big.
Alternatively, you could look at using custom performance counters. That would open the door to using System Monitor/perfmon as your monitoring tool, so no need to write any client code.
There are at least two ways to achieve that:
Your console application writes some logs, some state files, during its run, so other processes can read those files and understand what is going on in that console process.
Implement an IPC mechanism. There are different ways to do that. It may help you look in What is the easiest way to do inter process communication in C#?.
Is it possible when a file operation is called somehow - like open or close - that I can handle it before the request proceeds by the operating system and if possible cancel it by .NET? If .NET has no abilities like that, how can I do this?
What your asking to do can be done. Virus Scanners, for example, do it all the time. You can easily monitor file activity with Process Monitor. You can also do it programmically in C# using the FileSystemWatcher Class. But trying to prevent a program from opening up or trying to stop a program from accessing the file can not be done in C#. You will need to use either C or C++. You need to create a File System Filter Driver. It is a complex thing to build but its exactly what you need. To quote MSDN:
A file system filter driver intercepts requests targeted at a file system or another file system filter driver. By intercepting the request before it reaches its intended target, the filter driver can extend or replace functionality provided by the original target of the request. Examples of file system filter drivers include anti-virus filters, backup agents, and encryption products.
You can hook the Windows API if you want to. Check out this way to do that in .NET/C#:
EasyHook Windows API
Sysinternals offers a free tool called Process Monitor, one function of which is to attach to arbitrary Windows processes (including .NET applications) and capture system calls, including file open, close, read, etc.
You can download it at the Process Monitor Download Page.
EDIT
As I re-read your question, I see that you're asking about intercepting and possibly cancelling such operations. I believe the FileSystemWatcher class will be your best bet, although I don't think it can cancel file operations unilaterally - you'd need to build some kind of cooperative mechanism to signal the caller to abort its operation.
I'm pretty sure you've got to get into the kernel on that kind of operation and I'm pretty sure that means you'll need to code in C. Look at File System Drivers.
UPDATE: this SO link may help.
UPDATE: added a google search for Windows File System Drivers
ALSO What is a good resource to get started with Windows file system driver development?
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
We have a .NET application that we distribute to our users via an MSI installer package. We have C++ applications that run each morning to see if the user's copy of the application is out of date, and if so, we pull down the new MSI and install it. If the application is running, we need to take it down so we can perform the update.
Our problem is that every once in a while it seems like windows "loses" our application. It will not report that the process is running - though it is. It will allow us to overwrite, or even delete, the in-use executable file without taking down the application.
Maybe this is something that is common -- but we can't figure out what is going on! Does anyone have any insight into this situation?
It seems like a temporary copy of our application is getting created, and the program is getting ran from that. But if that is the case, why doesn't it happen all the time?
EDIT:
In our program, We are using the "EnumProcesses" function from the Platform SDK, PSAPI.dll, to enumerate all of the running processes.
Could it be that either the script or the application runs as a 64-bit program, and the other as a 32-bit program? If so, then on 64-bit machines the update check could be looking in the wrong location for an existing application and thus reporting it as missing?
What mechanism are you using to check to see if the process is running or not?
Try using something like process explorer to see what path the executable image is loaded from - it should be listed in the modules section.
I need to create an Intranet website (page) which allows users to indicate a local network folder to copy to a production location. Currently this is done manually using xcopy in batch files.
What I am looking for is approaches on triggering the copy so it's done in the middle of the night and an approach to copy the files. I suppose I can run xcopy from my application, but is this a good way to do this? Should I use System.IO name space objects to copy the files? Is there a better way all together?
The application will be written in C# and ASP.NET. We currently use .NET 2.0/3.0, but I have no issues using .NET 3.5 if it contains better libraries for the solution.
Basically a user will indicate which network folder they need copied along with some other business information. The folder indicated and all sub-folders need to be copied to target location (not set by user).
If there is already an application out there which does this, I am not opposed to that either. I have no need to write stuff that already exists.
For the first problem (copying at midnight), I suggest setting up a scheduled task that runs the already existing batch file (or any program, for that matter)
For the scheduling part you could use Quartz.NET
It won't be difficult to write an xcopy operation in C# using System.IO. In fact, this would give you the greatest degree of flexibility.
I think you should consider using Windows Powershell to do your copying (or another scripting language if you prefer), driven by Windows Scheduled Tasks. Though you could write an application to do this, I think it would be much more maintainable to have a script that others could edit.
The simplest solution would be to wrap your xcopy commands in a command file and schedule it to run whenever you want as a Scheduled Task on your web server.
If you want to get fancy, you can write up a web interface to the task scheduler - I'm pretty sure I've seen open source examples of that type of application too.
you've tagged this ASP but if you aren't fussy I'd recommend a combination of Windows builtin Scheduled Tasks and rsync. If it really has to be automated from an intranet page (and you're in IE) then some form of ActiveX or downloadable script/application would be needed to configure the schedule.