Reply to: Driver programmers

[AtW]

Different operating systems treat drivers in different ways hence my question about whether you knew what a driver was.

[doodab]

OK. I would normally assume C, but thought SY was working in C++. Do people commonly write in C++ or is it still considered bad, and everyone uses C?

From what I gather for kernel mode drivers C is the only real option as many C++ features aren't usable. For UMDF you can use either, but I don't know what people actually use.

Disclaimer: I am *not* an expert or professional driver programmer, just a compulsive tinkerer.

[d000hg]

I'm pretty sure he's using windows driver framework and it's written in C, based on his other posts.

OK. I would normally assume C, but thought SY was working in C++. Do people commonly write in C++ or is it still considered bad, and everyone uses C?

[d000hg]

So, you believe that a "plain old C++" driver will run under any other operating system, do you?

Different operating systems treat drivers in different ways hence my question about whether you knew what a driver was.

I didn't say Operating Systems. I said Operating System versions... I don't think he said what Windows version this is - 32/64 bit, XP/Vista/W7/2K3/2K8. Not sure if drivers are compatible or have to be rewritten for each Windows kernel but maybe trying on a different Windows version might yield extra information.

Or, since SY seems to be saying this is a big deal... hire someone who is a driver programmer to fix it.

[doodab]

I'm pretty sure he's using windows driver framework and it's written in C, based on his other posts.

[SupremeSpod]

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?

So, you believe that a "plain old C++" driver will run under any other operating system, do you?

Different operating systems treat drivers in different ways hence my question about whether you knew what a driver was.

[d000hg]

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.

[doodab]

Have you run it through the verifier in the WDK?

[SupremeSpod]

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?

[d000hg]

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?

[suityou01]

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.

[doodab]

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?

[AtW]

Atw?

Niet komrade.

[DimPrawn]

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

Atw?

[SupremeSpod]

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.