I've had this problem several times and until now not found a satisfying solution for it (restarting the computer is quite annoying if it takes 15 min to do so...):
When programming something with files, you have to use filestreams. The problem with them is (at least in C#) that they need to release the file again before you can access it from another place. As this is of course a good idea most of the time, it happened to me a few times that I forgot to release the file in the process of programming and debugging or the program crashed before the stream could be closed.
Is there any way to find and kill those streams using windows features or something like that? Problems like that occured in C# as well as in C++ (or C, I am not sure anymore).
From the answers I read, that this should not occur when the stream is handled properly. But what if I was to dumb to handle it right and the stream is not closed properly (because of whatever reason)? Is there a way to fix this while the PC is running?
This should not be a problem.
When your application is running normally, you use a using block to ensure that unmanaged resources like these are properly released. This is necessary for any object that implements the IDisposable interface.
If that fails, the operating system will jump in and save your bacon. The OS automatically releases any file handles that a process had open when it terminates, so even if your application crashes, there is no issue.
Anything that implements the IDisposable interface (which includes Streams) should always be either enclosed in a using block or be a member of a class which in turn implements IDisposable itself (and the new Dispose() method will also call the member's Dispose() method). There ought to be a compiler warning for this, imo.
Do this, and your file locks will be released properly.
Related
It has come to my attention that certain resources should be disposed of after utilizing them or closed etc;
Is there a rule of thumb as to what exactly should be closed / disposed?
Example - when you use StreamWriter , you want to close that when you are done to avoid errors etc. What are things that should absolutely be closed / disposed of and when?
The rule of thumb is... (drumroll, curtains pull back, pyrotechnics go up, and as the smoke clears)
Every time you are done using an object, if and only if the type1 implements System.IDisposable
Oh, you were expecting something complicated? Sorry to disappoint.
1The concrete type of the object. Sometimes that needs a runtime check, e.g. with IEnumerator implementations.
As #BenVoigt says, you should dispose of an IDisposable if you are done using that resource. C# introduced the using keyword for developers ease of use:
Example:
using (FileStream SourceStream = File.Open("file.ext", FileMode.Open)) {
//do something with the file
}
This keyword is a syntactical way to ensure that you dispose of your resource once you exit a method, etc. Of course some resources can be shared over multiple methods, threads, etc. so this language construct is not always available.
In many cases however, it's not that bad to forget to dispose of such object. If the program does no longer refers to it, the garbage collector will eventually walk by and dispose of it itself. Disposing of objects is however useful if the resource is large (a large file) or uses network resources (e.g.: a database connection). Since it releases resources that can be reused by other programs/users/clients/...
Furthermore disposing of objects is useful if they can be shared over multiple processes, threads, etc. like for instance files.: say you write to a file, then other programs need to wait until the write process has ended. If however program A waits for a file in use by process B and vice versa, a deadlock will occur: both programs wait for each other but don't give up their own resource. By disposing of such resources as soon as possible, most deadlocks will be prevented.
I have an interesting problem - I've inherited a large code base (brown field).
The application runs on a schedule and takes a large amount of data files (text) in, processes them, and then exports a report and cleans up.
There is a bug that has been discovered whereby when trying to clean up afterwards, some files are left in a locked state, even though all file activity has long gone out of scope. This stops the application from being able to delete them during clean up.
There are literally hundreds of IO and stream objects etc being used in this application, and I'm wanting to find out where to start looking to save reviewing every instance of their use.
What are some good tools for investigating File locks in c# managed code, and how do you use them to do so?
This happens normally when you forgot to dispose the parent object that owns a file handle. E.g. you forgot to call Close/Dispose to a FileStream. Then the finalizer will clean up the file handles when they are no longer referenced during the next full GC.
You can check with Windbg if you have SafeFileHandles in the finalization queue ready for finalization. A profiler which can track such things is e.g. YourKit which can when you enable probes also search for files closed in the finalizer and gives you the creation call stack which gives you the ability to search in your code for the offending line.
Check out the process Inspection tab of YourKit to find the probe check.
You can monitor file access (read/write) using ProcMon from SysInternals.
Its not specific to c# but a general tool that can be used for many other things. Note you can export the results to csv and investigate it later.
You can use one of the following guides:
Detailed Windows I/O: Process Monitor - How to do simple file monitoring.
Using Process Monitor to Monitor File Access - More detailed guide explaining how to export the results into a csv you can investigate later.
Edit:
I didn't found anything for this purpose, so if I was you I would inherit from the steam used, and wrap it with logging logic.
This logging stream object, for example named LogStream will write log before each method entrance, call the base.function() and write another log when done.
This way you can monitor the file access as you wish. For example, logging each stream instance an Id using Guid.NewGuid(), logging Thread Id using System.Threading.Thread.CurrentThread.ManagedThreadId etc.
This way you can identify the instances and slowly investigate the calls.
A point to start is to check whether there is equal number both stream open and close, an exception might avoided one of the Dispose() calls.
I have a ASP.NET C# singleton (scoped to a session through HttpContext.Current.Session) which receives messages from code (warnings, errors, exceptions etc.). The messages are related to code problems, mainly used while debugging, not during production.
I wrote the custom destructor for this object so that its contents are written/appended as a file on a disk.
I wanted to ask two things related to this situation:
a] Is is a good idea to open a file and write to it during object destructor? The concurrency IO access is handled through static lock.
b] When is the destructor called for session scoped objects? Is it only when the session is expired on the server?
I also recommend using some existing logging package. If you do decide to do this yourself, and just to bare in mind for the future:
a) No it's not a good idea. You shouldn't access managed resources in the finalizer (destructor), so if you have some log strings in memory for example, it's bad practice to access them (or the list they are contained in) as they may have already been finalized themselves at this point.
I don't want to repeat the recommended pattern, so see https://stackoverflow.com/a/1943856/2586804
You'll see there is only one place you should access managed during Dispose and this is if it is called by user code and not be the GC. So this should help you come to the conclusion that to achieve this, you must call .Dispose() yourself (or by using a using) as when (and if) the GC does it, it cannot access the managed members that contain the log lines.
b) Don't know, but it doesn't matter as you cannot use finalizer for this purpose anyway.
The bottom line is you can't rely on GC to run code for you. It's bad practice because you don't know when it's going to happen, plus any reference to the object anywhere, now or in the future will prevent the object being collected and introduce a bug.
You also shouldn't get c# Finalizers/Destructors to run code because that's not what they are for, they are for freeing unmanaged resources so that the machine doesn't run out. And note, it's a rare occurrence to use them in C# because most peoples day-to-day work is all with managed objects.
Instead explicitly tell the object to write it's logs, a method called Flush would be a good name. Or just let it write one line at a time. This would be the usual behaviour.
To accomplish this implement IDisposable and then wrap instances of your logger in a using block which will guarantee to call the dispose method on your logger.
I'm working on an application just now which uses a bunch of external DLLs to make a connection to a server somewhere. Oddly, the exposed methods for these DLLs allow a connection but NOT a disconnection or close. These libraries work fine unless you make a lot of subsequent calls to the server in one chunk, so what I decided to do was disconnect and reconnect after X amount of calls.
However, herein lies the issue. I cannot disconnect because no disconnect method is given. SO my question is, how can I totally kill this unmanaged object so I can recreate it again?
If you're using unmanaged resources in C# you should have your classes that use and interact with the unmanaged resources implementing IDisposable and creating and destroying them with using blocks.
If you can't disconnect, depending on exactly what you're interfacing sometimes setting the variable containing your unmanaged resource to null will clear some of it up. Really though, there's not a great deal you can do without proper disconnect/dispose methods.
You could manually close the underlying connection to the server. I cant help you any more with how to do that without knowing more about the service your consuming (HTTP TCP ect?). You could put a trace (like wireshark) up and see what's being transferred.
Bottom line though is their software is broken. Can you not contact the vendor?
The best solution I could find for this, was to run each call to the external DLL in it's own thread, which was eventually killed when the thread ended. This was the only resolution that worked, given I had no access to updated DLLs.
Well, here I am again with another frustrating question.
I need to end my main process and restart it, but I can't just end the application gracefully...
I am using a C# application in conjunction with proprietary (not to me) data capture hardware, so right there it's already complicated.
There is a scenario when my software is happily running, collecting its data as it should, when the hardware I'm interfacing with suddenly loses power and the connection to my application. My application eventually figures this out and I just need to dispose of my old connection, and make a new one to connect to my hardware again. Wrong...
Of course, the .Dispose() method on my object (the interface object with the hardware), that terminates the connection does nothing, and actually just locks in place forever when I try to run it. Apparently there is some kind of communication that never times out on the dispose method that requires the device to be connected when the disconnection happens. I didn't write the method, so I don't really know.
Finally, here's my question. The only way to get my application up and running again is to close it and reopen it. Of course, I can't actually close it nicely because I can't run the Dispose method. I am forced to end it's process via task-manager. Yes, the process, not just the application. If I just close it, the process will stay alive forever, I have no choice.
I need to find a way to automate this process assassination so my users can actually use it, but what can I do? I know process termination is taboo, but what options do I have?
I'd love to use Application.Restart(), but that doesn't work at all, my form doesn't even close, it just locks. Is there a way to axe the process just before telling itself to launch again? Maybe I can do this with a batch file or something? Application.Exit at least takes the form off the screen.
As of now, I'm killing it from Task Manager, or my users are killing it by popping the breaker on the PC. Considerably more harsh than anything software-wise.
Have you considered isolating the problematic component in another process? I know it sounds complicated, but if you create another "application" which solely exists as a conduit to your device, you can make your main application just start a new one of those if the old one becomes unresponsive. It can nuke the old one, start a new one, and be "clean" again.
It does mean all kinds of inter-process communication of course, but the general idea of isolating something flaky is often a useful one.
Assuming that it is Dispose() that is the problem and that there is a proper IDisposable pattern implementation where the finalizer calls Dispose() I think that a solution might be to call GC.SupressFinalize(objWithFailingDispose) to prevent Dispose from being called at all.
It is ugly, but I might work.
This question should probably be titled "What do I do when I'm dealing with a Dispose() method I can't change, and has been written without considering a very real and very troubling real-world scenario?" And my suggestion would be to write a better one!
The simplest approach would be to create a wrapper for the object that will be disposed, and then calling GC.SuppressFinalize(internalConnectionObject); if you've detected that the connection has dropped. That way, if it's not responsive, it won't get stuck, but if it's there, it will be disposed properly. Isolation is your friend when you have troublesome components.