C
Cyril Madigan
This is a bespoke application that has been developed
using C# (Smart Device Application Template) targetting
Windows CE .NET (4.1), CPU = XScale running on Symbol
handheld scanning devices.
It uses multiple threads to perform background tasks while
the user continues to scan barcodes. The application was
originally developed for a Windows CE 3.0 device but has
recently been deployed onto
Windows .NET 4.1 devices using the Intel XScale PXA250
processor.
Since moving onto the new platform we have started
xperiencing a recurring problem where the application
freezes and the device has to be 'warm' booted for the
user to continue. We have been able to replicate the
problem with our development devices and through debugging
the application we think that the problem ultimatly is
caused by background threads being terminated unexpectedly
without any notification. No errors or exceptions are
being generated when this happens.
The application freezing is a by-product - if a thread
with a lock on the database resource is terminated before
it releases the lock, all future attempts to use the
database resource stall.
Although we are not certain of the cause, we came to this
conclusion by adding logging statements within a
particular method and when the application froze, looking
at the log file to see how far it got. We found that in
one circumstance the thread terminated just before or
while executing a very simple statement as shown below:
while (!endOfWork)
{
// Write message to log (A)
if (index != specialIndex)
{
// Write message to log (B)
// Do some work
// Write message to log (C)
}
// Write message to log (D)
}
The log resulted in a stream of messages such as:
A, B, C, D, A, D, A, D, A, D, A, B, C, D, A
So the thread successfully executed a number of
itterations of the loop but then suddenly stopped just
before or while evaluating the expression inside
the 'if'. A try/catch block around the while loop did not
catch any exceptions.
We had also set the debugger exception options to break
immediately into the debugger whenever any C++ Exceptions,
Common Language Runtime Exceptions, Native Run-Time Checks
or Win32 Exceptions occurred but this never kicked
in.
If we pause the application once we detect a 'freeze', the
thread which should be executing this code is not
displayed in the debuggers list of threads.
However a hashtable which maintains a reference to
all 'managed' threads that have aquired a lock on the
database resource still reports the existance of the
original thread.
Most (if not all) of the background threads are initiated
by a System.Threading.Timer instance.
Any assistance or pointers would be much appreciated.
using C# (Smart Device Application Template) targetting
Windows CE .NET (4.1), CPU = XScale running on Symbol
handheld scanning devices.
It uses multiple threads to perform background tasks while
the user continues to scan barcodes. The application was
originally developed for a Windows CE 3.0 device but has
recently been deployed onto
Windows .NET 4.1 devices using the Intel XScale PXA250
processor.
Since moving onto the new platform we have started
xperiencing a recurring problem where the application
freezes and the device has to be 'warm' booted for the
user to continue. We have been able to replicate the
problem with our development devices and through debugging
the application we think that the problem ultimatly is
caused by background threads being terminated unexpectedly
without any notification. No errors or exceptions are
being generated when this happens.
The application freezing is a by-product - if a thread
with a lock on the database resource is terminated before
it releases the lock, all future attempts to use the
database resource stall.
Although we are not certain of the cause, we came to this
conclusion by adding logging statements within a
particular method and when the application froze, looking
at the log file to see how far it got. We found that in
one circumstance the thread terminated just before or
while executing a very simple statement as shown below:
while (!endOfWork)
{
// Write message to log (A)
if (index != specialIndex)
{
// Write message to log (B)
// Do some work
// Write message to log (C)
}
// Write message to log (D)
}
The log resulted in a stream of messages such as:
A, B, C, D, A, D, A, D, A, D, A, B, C, D, A
So the thread successfully executed a number of
itterations of the loop but then suddenly stopped just
before or while evaluating the expression inside
the 'if'. A try/catch block around the while loop did not
catch any exceptions.
We had also set the debugger exception options to break
immediately into the debugger whenever any C++ Exceptions,
Common Language Runtime Exceptions, Native Run-Time Checks
or Win32 Exceptions occurred but this never kicked
in.
If we pause the application once we detect a 'freeze', the
thread which should be executing this code is not
displayed in the debuggers list of threads.
However a hashtable which maintains a reference to
all 'managed' threads that have aquired a lock on the
database resource still reports the existance of the
original thread.
Most (if not all) of the background threads are initiated
by a System.Threading.Timer instance.
Any assistance or pointers would be much appreciated.