Driver programmers

**SupremeSpod** · 9 August 2010, 11:17

Originally posted by suityou01 View Post

Does anyone on here write drivers? I have a WFP driver I am writing which is driving me round the bend. It essentially works, and does everything I want, but during driver shutdown it blue screens. The faulting code is RemoveEntryList which basically means that two threads are trying to remove the same Linked List entry. One gets there first, the later thread then finds bogus memory and hence the BSOD. I think I have been very disciplined with my use of spinlocks so I am buggered if I know what the hell is going on.

I am not a driver writer by any stretch, and there is probably an obvious explanation to someone in the know. All I have is the source code and the minidump run up in windbg.

Need a little help.

The "Singleton" is probably the best thing you should be researching at just this moment in time.

**DimPrawn** · 9 August 2010, 11:22

Originally posted by SupremeSpod View Post

The "Singleton" is probably the best thing you should be researching at just this moment in time.

Atw?

**AtW** · 9 August 2010, 21:05

Originally posted by DimPrawn View Post

Atw?

Niet komrade.

**doodab** · 10 August 2010, 08:30

Why is the second thread using a stale reference to shared data?

Surely you aren't holding local copies that are getting staled. Is the second, faulting, thread perhaps obtaining a reference to a list item BEFORE obtaining the relevant lock when it should be locking first?

**suityou01** · 10 August 2010, 19:33

Originally posted by doodab View Post

Why is the second thread using a stale reference to shared data?

Surely you aren't holding local copies that are getting staled. Is the second, faulting, thread perhaps obtaining a reference to a list item BEFORE obtaining the relevant lock when it should be locking first?

No the lists are all global and spinlocks are observed with rigour. The crashdump (stackdump) shows that it is the driver unload that is causing the bsod. I have no idea why, and really think the only way to pin this down is to use remote kernel debugging.

So I bought a serial card, null modem cable and set it all up. I set the kernel debugger to run, reboot the target machine into the debugged windows session, and frak all. Nada. Zip. Nichts. Diddly. FA.

About 2 years dev effort (on and off) has gone into this and unless I can stabilise it I am going nowhere. I even contacted a driver writing firm in the states who have not replied.

So at this point, with nowhere to turn and not being able to set up kernel debugging I am looking pretty stuffed.

**d000hg** · 12 August 2010, 11:18

Get anywhere? What other forums have you posted on - there must be a Windows Driver development MSDN group? Assuming it's for Windows that is... have you tried on multiple OS versions to see it's consistent?

This is plain old C++, right?

**SupremeSpod** · 12 August 2010, 14:17

Originally posted by d000hg View Post

Get anywhere? What other forums have you posted on - there must be a Windows Driver development MSDN group? Assuming it's for Windows that is... have you tried on multiple OS versions to see it's consistent?

This is plain old C++, right?

Do you know what a device driver is?

**doodab** · 12 August 2010, 15:23

Have you run it through the verifier in the WDK?

**d000hg** · 16 August 2010, 13:04

Originally posted by SupremeSpod View Post

Do you know what a device driver is?

You can write them in ASM, C, C++, not to mention Pascal or anything else compiling to direct binaries which is C-interoperable. SY doesn't say it's C or C++, which are the obvious choices especially based on his previous posts, the former is more traditional for driver-writing but C++ is quite appropriate although more tricky.

Really, you should stop pretending to know what you're talking about.

Driver programmers