Develop Reference

How to fix random FileSystemEnumerableIterator.MoveNext Error. The handle is invalid

I just started randomly getting the error on a program that has been running for years. all this program does is look at a set of directories and delete files based on their last write time.
Here is the error and stack trace.
Error: The handle is invalid.
Stack Trace: at System.IO.__Error.WinIOError(Int32 errorCode, String
maybeFullPath) at System.IO.FileSystemEnumerableIterator`1.MoveNext()
at DirectoryCleaner.Program.GetNewFiles()
Here is the code
DirectoryInfo di = new DirectoryInfo(sourcePath);
foreach (FileSystemInfo file in di.EnumerateFileSystemInfos(variablePattern == true ? "*" : SearchPattern, searchSubDirectories == true ? SearchOption.AllDirectories : SearchOption.TopDirectoryOnly))
{
creates queue of records to delete. I removed the logic as it is rather long...
}
I have spent several hours searching. I found
System.IO.IOException: The handle is invalid, when using Directory.EnumerateDirectories but it does not have an answer.
The stack trace shows that it is in the MoveNext method which I do not directly call. I assume the foreach loop calls it. How can I correct what is causing this?

This error occurs because the various file/directory EnumerateX methods are effectively wrappers around the native Win32 FindFirstFile function, and as per its documentation:
If the function fails or fails to locate files from the search string in the lpFileName parameter, the return value is INVALID_HANDLE_VALUE and the contents of lpFindFileData are indeterminate. To get extended error information, call the GetLastError function.
If we look at the relevant portion of the Framework Reference Source, we see that any error not handled explicitly is surfaced as an IOException. This would include INVALID_HANDLE_VALUE.
In other words, this is an expected potential exception while calling an EnumerateX method and your code should handle it correctly by catching the generic IOException. The docs for the various EnumerateX methods fail to call this out, which IMO is an omission, and as such I've opened an issue to get that fixed.

Index was outside the bounds of the array in calling WCF API

I have developed a web application with ASP.net(C#, .Net Framework 4.0) in some part of the application I am calling an API to get some information. I noticed that some of the calls to API are failed and I got this error:
Index was outside the bounds of the array.
when I checked the stack trace I saw this :
at System.Collections.Generic.Dictionary2.Insert(TKey key, TValue value, Boolean add)
at System.Collections.Generic.Dictionary2.set_Item(TKey key, TValue
value)
at Navitaire.Ncl.Validation.ValidationManager.getValidationAttributes(MemberInfo mi, Boolean& skip)
at Navitaire.Ncl.Validation.ValidationManager.validate(Object declaringObject, Object value, MemberInfo mi, List1 results)
at Navitaire.Ncl.Validation.ValidationManager.Validate(Object obj)
at Navitaire.Ncl.ServiceModel.ParameterValidationInspector.BeforeCall(String operationName, Object[] inputs)
at Navitaire.Ncl.ServiceModel.Remoting.BoilerplateSinkBase.InvokeBeforeCallInspectors(StateData stateData, RemotingMessage& message)
at Navitaire.Ncl.ServiceModel.Remoting.BoilerplateServerSink.ProcessMessage(IServerChannelSinkStacksinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders&
responseHeaders, Stream& responseStream)
at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders&
responseHeaders, Stream& responseStream)
I put a break point on the catch exception part, so every time that I got the error, application will stop and I can read the exception. I noticed that if in this moment I call the API again (move the cursor to the API call line) it works fine. so it means there is no problem with parameter that I am passing to the API.
I tried to run the application on three different environments with totally different network and different internet connection, but still I got the same error.
Can you please someone help me on this case?
Thanks

I suspect this is a problem with the API, rather than your code, especially if it works the second time you make the same call.
I believe the API is doing something with an internal dictionary, that doesn't quite get set up correctly the first time you call it, but by the second time, it has been and works "correctly".
Are you able to view / have access to the code for the API method your calling?
If so, you are best running that in debug alongside your application, placing a breakpoint on the entry to that method and stepping over the lines within it to see what it is doing and why it may be breaking.
If it's your API, or you're allowed to share the code of this method and you can't find the error yourself, please post up the code of the API method and I'll help you find what the cause could be.
If you are not able to view the code, I would suggest contacting the producer of the API if it's a private one, or if it's an open source API, share the link and provide a code sample of what your code looks like (showing how you make the API call) and we can help diagnose it.

I checked with the API developer and I found that there was some thing wrong on their side after they fixed the bug I did not get any error anymore.

What exception to throw to indicate child process freezed

Question 1 - practical
I run child process in my C# application using System.Diagnostics.Process. Like the following:
Process process = new Process();
// ... StartInfo initialization here
int timelimit_ms = 30000;
process.Start();
if (!process.WaitForExit(timelimit_ms))
{
// What exception to throw here?
throw new Excpetion(
"An executing method exceeded the time limit of " + timelimit_ms.ToString() + "ms");
}
I'm currently throwing System.ComponentModel.Win32Exception. But I don't sure it is the best choice. The child process is a simple command line utility. So the first question, what exception to throw in this situation?
Question 2 - thoretical
This is not the first time I ask myself about what exception to throw. And I don't know of a simple guidelines on how to pick a certain one. There are so much exceptions in C#, deeply inherited from one namespace to another. The second question, how to decide what exception to throw in a specific situation?

Practically, I'd throw a TimeoutException as it describes what is happening
Theoretically, if a quick google / read of the docs doesn't throw up an exception that already describes what is happening then you can just extend Exception to generate a WeirdThingThatHappensSometimesInMyApplication Exception.
But it depends who or what is going to "read" your exception. If your exception isn't exceptional then maybe you should do things differently :-)

how about a timeout exception?

I would think about throwing InvalidOperationException from the code.
As states MSDN, this exception is:
The exception that is thrown when a method call is invalid for the
object's current state.
So the caller of the function or consumer of the object that runs and waits for the process will be notified about the fact that execution of the function failed.
If you want to be detailed about declaration of the failure reason, you can express it
or in detailed message (if it's enough)
or create yuor own custom exception derived from InvalidOperationException and populate it with additional data you may need outside from the caller.

exception call stack truncated without any re-throwing

I have an unusual case where I have a very simple Exception getting thrown and caught in the same method. It isn’t re-thrown (the usual kind of problem naïve programmers have). And yet its StackFrame contains only one the current method. Here’s what it looks like:
at (my class).MyMethod() in C:\(my file path and line)
In reality there are probably 30 methods leading up to this in the VS2010 debugger's call stack, going across half a dozen different assemblies. It seems impossible for all that to have been optimized out. Moreover, this code is built in debug mode, without optimizations, for .NET 4. I even have (based on http://msdn.microsoft.com/en-us/library/9dd8z24x.aspx) .ini files (including one named [app].vshost.ini) in the same folder containing:
[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0
Also, the method calls are not at the end of methods, so tail-recursion optimization seems further unlikely.
As to how it is called: there are no uses of reflection on the call stack, no Invoke() or BeginInvoke() of any kind. This is just a long chain of calls from a button click. The click handler is about 10 calls down the call stack. Beneath that you have the usual WndProc, NativeWindow.Callback, native/managed transitions, and message loop. This is ultimately inside a ShowDialog() call which is run from a C# EXE assembly.
Now, I found that I can construct instances of the StackTrace class in my catch handler, and if I pass the Exception object, the call stack is also short. If instead I just call new StackTrace() with no arguments, it yields a complete call stack.
I’ve used Reflector in an attempt to debug into the internals of the Exception class getting thrown and its call stack constructed, but I couldn’t set breakpoints in Exception or in StackTrace. I could set them in Environment.GetStackTrace() and this method (which Exception calls) does not appear to get called during the construction and throwing process, but I don’t know if the debugger is really working properly. (This method does get triggered for some other things though, so I'm not sure what to make of it.)
Here’s an excerpt of the method:
private void MyMethod()
{
...
try
{
throw new ApplicationException("Test failure");
}
catch (Exception e)
{
StackTrace stackTrace1 = new StackTrace(e);
StackTrace stackTrace2 = new StackTrace(e, false);
StackTrace stackTrace3 = new StackTrace(e, true);
StackTrace stackTrace4 = new StackTrace();
string STs = stackTrace1.ToString() + "\n---\n"
+ stackTrace2.ToString() + "\n---\n"
+ stackTrace3.ToString() + "\n---\n"
+ stackTrace4.ToString();
Log(EventSeverity.Debug, STs);
...
}
}
It’s really pretty simple: Throw exception, catch and log it.
I get the same results either in the debugger or when running standalone—a one-line call stack. And I know I have seen this problem elsewhere in our code base. Previously I had assumed it was due to re-throwing exceptions, but in a lot of cases it we log right inside the initial catch block. I’m quite baffled and all the web searching I’ve done hasn’t produce anything.
This is a little too much to add as a comment to the answer provided, but here's some more information:
I now see that this behavior is discussed at
http://dotnetthoughts.wordpress.com/2007/10/27/where-did-my-exception-occur/ and that it is actually described at http://msdn.microsoft.com/en-us/library/system.exception.stacktrace.aspx (though I think one could easily miss what they're saying there).
So I guess my "solution" will be a little hit-or-miss. We have a central method we usually call to format exceptions. Inside that method, I'll create a new StackTrace() both with and without the Exception object. Then I'll look for the method that is at the bottom of the Exception's stack trace, and display everything beneath that in the new StackTrace(), indicating it was called by that series of calls.
The down side of course is that if this method isn't used, the information won't be there. But I had to expect some kind of code change somewhere.

When an exception is thrown, only a partial stack trace will be used in the Exception.StackTrace property. The stack only shows calls up until the method that is catching the exception. To get the full stack (as you have noted) you should create a new StackTrace() object.
I can't find any links on it at the moment but I believe the stack trace is built by walking up the stack while throwing the exception. Once the exception reaches a catch block, the stack stops being compiled. Therefore, you only get a partial stack.
Typically, a catch block is not concerned with who called it, but where the exception is originating from.

Problem with Environment.StackTrace

On a thread that is processing new data in the system, if the data is invalid I write a message in the event log, containing the Environment.StackTrace information.
Writing in the event log throws an exception with no text message
Message:
CallStack - at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
at System.Environment.get_StackTrace()
at <my method that writes in the event log>
Any ideas why this happens?
EDIT: I am interested in what can cause the Environment.StackTrace to throw exception in general, so that i can understand what is happening in my case

#anchandra I don't know if you have figured this out since, as this is now 4 years old.
However I would like to add as I just stumbled upon this myself.
So, why does Environment.StackTrace throws an exception?
First the most uninteresting answer:
As you can see in the MSDN reference to the property, it can throw an ArgumentOutOfRangeException if "The requested stack trace information is out of range.", note also that the executing context must have System.Security.Permissions.EnvironmentPermission.
Now what stumped me for a second:
It does NOT throw an exception! Yes, that is what was happening to me, it actually returned me a Stack Trace that started listing the call to Environment.StackTrace like "at System.Environment.get_StackTrace()" then it showed all the other calling methods.
Because I was logging this into an audit log, if you look at it you assume there is an exception occurring at the last frame of the stack, but that's not true, I was just happening to request a Stack Trace at that point and stick it in my error log, very dumb once I realized this.

You need to capture the stacktrace before moving onto a separate thread.
Stacktrace will only show you the frames up to the root of the thread.