At least your last report confirms that I did not see a flaw, except the one with exception. You should remove your "exception handling". You actually suppressing propagation of exceptions. What could happen?
Suppose, on one computer you use the directory which your program has no access to. It often happens to careless programs on Windows 7. By some reason, on other system you do have access. I can see that you are using hard-coded path names in the code. There are no situations where such paths can be useful, but in simple case you can use, say, working directory; typically, in simple console programs you can execute in different working directories. You cannot assume in your code anything related to a particular working directory. This is something not related to the location of your assembly or nothing at all. The user can execute your program from any directories at all, and it will change the locations of paths you are working with. Some use absolute paths; this is even worse.
The program work in one case and throws exception in another. There is no such thing as miracle. Now, as you block propagation of all exceptions, I am not sure that you can see the exception at all. Look, in one case you use
, is some other —
. Either of them can be hidden from you. If console is not available (non-console applications), a console output works, but remains completely invisible to the user. This was not a
which always works.
As a rule of thumb, the exceptions should be caught only on the top of stack of each thread and processed properly. For UI, there is a special way to handle exceptions in the main event cycle (depends on UI library, WPF or Forms). Please see my past answers on the problem.
When i run an application an exception is caught how to handle this?
throw . .then ... rethrowing
Error Logging and Screen Shot.
Catching an Exception
Handling exceptions in class library (dll)