Context Switch Deadlock Was Detected

[Ian Semmel]

I am doing a length operation reading access database and creating a sql
database when I get this message.

What am I supposed to do to get around it ?

Thanks

[Willy Denoyette [MVP]]

"Ian Semmel" <is***********@NOKUNKrocketcomp.com.au> wrote in message
news:Op**************@TK2MSFTNGP09.phx.gbl...
|I am doing a length operation reading access database and creating a sql
| database when I get this message.
|
| What am I supposed to do to get around it ?
|
| Thanks

Will need some context to answer this question, what kind of application is
this (Console, windows, service, other). How many threads and kind of...

Willy.

[Ian Semmel]

Well, I'm new to C# and Winforms etc but ..

It is a windows application, which (in part), reads an Access dataset and
creates an sql server dataset. Nothing much else is going on except a progress
bar updating. There are no threads.

I've discovered it works outside of VS so it's not too bad.

Willy Denoyette [MVP] wrote:

"Ian Semmel" <is***********@NOKUNKrocketcomp.com.au> wrote in message
news:Op**************@TK2MSFTNGP09.phx.gbl...
|I am doing a length operation reading access database and creating a sql
| database when I get this message.
|
| What am I supposed to do to get around it ?
|
| Thanks

Will need some context to answer this question, what kind of application is
this (Console, windows, service, other). How many threads and kind of...

Willy.

[Willy Denoyette [MVP]]

The point that it doesn't show up is because the possible deadlock detection
is switched 'off' in a release build and 'on' when running in the debugger.
But it's bad, don't let there be any mistake about it. You problem relates
to the time the UI thread is blocked when accessing Access before returning,
or more precisely, the period of time in which no messages are getting
dispatched from the UI thread's message queue is way too long, the CLR
considers this as a possible deadlock. What you should do is move this task
to an other thread and update the progress bar using Control.Invoke or
Control.BeginInvoke.
Another option is to use a console application for this kind of batch
process.

Willy.


"Ian Semmel" <is***********@NOKUNKrocketcomp.com.au> wrote in message
news:uZ*************@TK2MSFTNGP09.phx.gbl...
| Well, I'm new to C# and Winforms etc but ..
|
| It is a windows application, which (in part), reads an Access dataset and
| creates an sql server dataset. Nothing much else is going on except a
progress
| bar updating. There are no threads.
|
| I've discovered it works outside of VS so it's not too bad.
|
| Willy Denoyette [MVP] wrote:
| > "Ian Semmel" <is***********@NOKUNKrocketcomp.com.au> wrote in message
| > news:Op**************@TK2MSFTNGP09.phx.gbl...
| > |I am doing a length operation reading access database and creating a
sql
| > | database when I get this message.
| > |
| > | What am I supposed to do to get around it ?
| > |
| > | Thanks
| >
| > Will need some context to answer this question, what kind of application
is
| > this (Console, windows, service, other). How many threads and kind of...
| >
| > Willy.
| >
| >

[Ian Semmel]

Yes, I see your point. This is a once-only job so I might leave it.

I also get this error when debugging the program. I would have thought that the
rts would have been able to avoid it but it seems not.

However, is there a way (without using threads) that I can tell the system that
I'm still alive or can I increase the 60 seconds value that the environment uses
before it craps out ?

Willy Denoyette [MVP] wrote:

The point that it doesn't show up is because the possible deadlock detection
is switched 'off' in a release build and 'on' when running in the debugger.
But it's bad, don't let there be any mistake about it. You problem relates
to the time the UI thread is blocked when accessing Access before returning,
or more precisely, the period of time in which no messages are getting
dispatched from the UI thread's message queue is way too long, the CLR
considers this as a possible deadlock. What you should do is move this task
to an other thread and update the progress bar using Control.Invoke or
Control.BeginInvoke.
Another option is to use a console application for this kind of batch
process.

Willy.


"Ian Semmel" <is***********@NOKUNKrocketcomp.com.au> wrote in message
news:uZ*************@TK2MSFTNGP09.phx.gbl...
| Well, I'm new to C# and Winforms etc but ..
|
| It is a windows application, which (in part), reads an Access dataset and
| creates an sql server dataset. Nothing much else is going on except a
progress
| bar updating. There are no threads.
|
| I've discovered it works outside of VS so it's not too bad.
|
| Willy Denoyette [MVP] wrote:
| > "Ian Semmel" <is***********@NOKUNKrocketcomp.com.au> wrote in message
| > news:Op**************@TK2MSFTNGP09.phx.gbl...
| > |I am doing a length operation reading access database and creating a
sql
| > | database when I get this message.
| > |
| > | What am I supposed to do to get around it ?
| > |
| > | Thanks
| >
| > Will need some context to answer this question, what kind of application
is
| > this (Console, windows, service, other). How many threads and kind of...
| >
| > Willy.
| >
| >