Program runs under debug mode but stalls in normal mode

[Jothishankar]

Hi,

I am new to c#. I am trying to build an application that does backup
of files to an external hard disk.

My application behaves strangely. When i run the application under
debug mode (F5), it works properly. But when i run it in normal mode
(Ctrl+F5) the program stalls in the middle.

I use a couple of worker threads which run successively. The first one
is for estimating the space requirements - calculating the folder size
to backup and also finding the available disk space on the external
hard disk.

After the first thread completes, the second worker thread does the
actual backup. The main thread handles the UI. The two worker threads
update the UI components in the main thread in a thread safe manner.

All these work properly in the debug mode. But in the normal mode, the
program stalls during the backup. It stops in the middle and the
backup does not complete. Also, the program does not respond.

FYI, I am building the application under "debug" and not "release"
configuration.

Any help appreciated.

Thank you.

 

[Peter Duniho]

I am new to c#. I am trying to build an application that does backup
of files to an external hard disk.

My application behaves strangely. When i run the application under
debug mode (F5), it works properly. But when i run it in normal mode
(Ctrl+F5) the program stalls in the middle.

Well, what is it doing when it stalls? You can attach the debugger to
the process and examine the state of the program, which should tell you
where it has stalled.

Based on your description of the program, I suspect you have an error in
your threading code and have created a deadlock situation somewhere.
But the first step, whatever the problem, is for you to get a stack
trace and figure out exactly where the program is stuck.

Pete

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Hi,

I am new to c#. I am trying to build an application that does backup
of files to an external hard disk.

My application behaves strangely. When i run the application under
debug mode (F5), it works properly. But when i run it in normal mode
(Ctrl+F5) the program stalls in the middle.

I use a couple of worker threads which run successively. The first one
is for estimating the space requirements - calculating the folder size
to backup and also finding the available disk space on the external
hard disk.

After the first thread completes, the second worker thread does the
actual backup. The main thread handles the UI. The two worker threads
update the UI components in the main thread in a thread safe manner.

What you mean with a Thread safe mode?
Are you using Control.Invoke to update the UI?

 

[Jothishankar]

Hi,










What you mean with a Thread safe mode?
Are you using Control.Invoke to update the UI?

Yes. I am using Invoke to update the UI.

 

[Jothishankar]

Well, what is it doing when it stalls? You can attach the debugger to
the process and examine the state of the program, which should tell you
where it has stalled.

Based on your description of the program, I suspect you have an error in
your threading code and have created a deadlock situation somewhere.
But the first step, whatever the problem, is for you to get a stack
trace and figure out exactly where the program is stuck.

Pete

If there is a deadlock situation in the code, shouldn't it come up
when i run it the debug mode? I have tested it many times, and this
does not happen when i run in debug mode.

After running the program (Ctrl+F5), i attached the process to the
debugger. But the debugger does not give anything related to the
stalling. It is as if the program is running normally. But although, i
am curious as to why my threads do not show up in the Thread window of
the debugger.

 

[Peter Duniho]

If there is a deadlock situation in the code, shouldn't it come up
when i run it the debug mode? I have tested it many times, and this
does not happen when i run in debug mode.

Not necessarily. Except for the most blatant examples, deadlock can be
very sensitive to the exact timing of the code. Any difference in how
the code runs can affect whether the deadlock is reproducible.

That said...

After running the program (Ctrl+F5), i attached the process to the
debugger. But the debugger does not give anything related to the
stalling. It is as if the program is running normally. But although, i
am curious as to why my threads do not show up in the Thread window of
the debugger.

If there are threads you expect to see, but which are not displayed, I
would suggest that is not "as if the program is running normally".

In particular, if the threads aren't there, then they exited (normally
or abnormally, hard to say). If your program needs those threads around
in order for it to do work, then I'd say that the lack of the threads
being present is a pretty good indication of what's wrong.

Why the threads aren't there, and why they don't exit when you run the
application under the debugger, I can't say. The first thing I'd try is
putting an exception handler at the very top of each thread's entry
procedure, since it seems like the most likely reason they'd just
disappear silently would be an exception. This _might_ at least help
answer the first question, even if not the second.

Pete

 

[Guest]

Aside from other valid suggestions like attaching debugger, I'd suggest that
you try to wire up your code better for exception handling and logging. If
you have good exception handling and can log any exceptions to a file, the
event log, or to a database (including code that catches and logs the
unhandled exception events) then you'll be in a position to get better
metrics about what is going on. Finally, don't run a debug build to do this
testing - make a release build.
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

 

[Jothishankar]

Aside from other valid suggestions like attaching debugger, I'd suggest that
you try to wire up your code better for exception handling and logging. If
you have good exception handling and can log any exceptions to a file, the
event log, or to a database (including code that catches and logs the
unhandled exception events) then you'll be in a position to get better
metrics about what is going on. Finally, don't run a debug build to do this
testing - make a release build.
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

I cannot get the stack trace because, the program runs properly 100%
of the time in debug mode. Only when i run it in normal mode, this
problem happens. I also did a "Attach to Process", but that also does
not give any debug info.

 

[Jothishankar]

I cannot get the stack trace because, the program runs properly 100%
of the time in debug mode. Only when i run it in normal mode, this
problem happens. I also did a "Attach to Process", but that also does
not give any debug info.

Finally, i have figured out what the problem was. I am using a
DataGrid control to show the status of the backup process. I did not
make that thread safe. That was causing the whole problem. After
correcting that (by calling the Invoke the DataGrid control), it works
fine.

I have a separate question with regards to the the DataGrid control.
How can i make it scroll automatically when i add rows to the
DataTable object which is the datasource for the DataGrid ?

Thanks

 

[Peter Duniho]

[...]
I have a separate question with regards to the the DataGrid control.
How can i make it scroll automatically when i add rows to the
DataTable object which is the datasource for the DataGrid ?

A suggestion: if you are going to ask a new question completely
different from your original, start a new thread.

This is always a good idea, but even more so when your original question
was fairly esoteric and thus much more likely to be ignored by a wider
audience.

Pete