Hi,

I am bit new to driver programming. I would like to know how to prevent
context switching between threads.

Here is the scenario:

Thread A is running at PASSIVE LEVEL, driver gets into some funny state and
hence I want to panic the system so that I can get a memory dump to diaognise
the problem. So before crashing, I copy required data in a temporary buffer.
When I am about to panic the system, another thread B gets scheduled,
pre-empts the already running thread A, does context switching and runs for a
short burst and clear the data from my main buffer. Once thread B finshes,
thread A resumes the operation and panics the system. When I analyze memory
dump, I notice that contents in temp buffer and main buffer differ because of
context switching.

I want to know how do I prevent this context switching between threads A and
B? As soon as I get into funny state, I want to copy the data in temporary
buffer and crash the system.

Thanks.

Simple, use a dispatcher object to sync access to the
data. See help for KeInitializeEvent() and
SynchronizationEvent.

If either thread can run at DISPATCH_LEVEL, then use a
spinlock instead.

Steve.

Use a Spin lock to raise to DISPATCH_LEVEL, save your data, then lower to
PASSIVE. But I would simply panic, crash and then analyze the dump. I know
enough to copy the data, I therefore should know enough to find the data in
a dump.

--
Gary G. Little

"Nikhil" <Nikhil@discussions.microsoft.com> wrote in message
news:01D6DE60-FBBB-4D1D-B915-C2919E68EB6B@microsoft.com...

Thank you. I raised IRQL level to DISPATCH_LEVEL to solve the problem.

"Gary G. Little" wrote:

You realize this is just a 'quick fix' and will never work in production?
Thread 'B' can run on SMP systems. This includes the HT and dual core CPUs
as well as the Xenon, MP, and Opteron systems. Access to the buffer must be
controlled. If 'A' needs the buffer it must have a way to stop 'B' from
touching the buffer. The reverse is also true. We no longer write code for
the 8088 running DOS, except for BIOS and embedded folks.

"Nikhil" <Nikhil@discussions.microsoft.com> wrote in message
news:379256C1-AF66-4381-9171-341C02F5791A@microsoft.com...