The KeInitializeSpinLock function always succeeds, as long as you have provided a pointer to valid memory (non-paged pool). If you provide a pointer to invalid memory, you’re headed down the bug-check path, which is why I say the function “always succeeds”; the function either succeeds, or you’ve blown up the machine.
KeInitializeSpinLock initializes a block of memory, whose length is sizeof(KSPIN_LOCK), to a known state. Why are you surprised that the valid state consists of zero? That’s an implementation detail. KeInitializeSpinLock’s job is to bring that memory to a *known state*, rather than containing whatever random garbage it contains.
You’re never supposed to make any assumptions about how spin locks are implemented, but the current reality is that zero is the “unacquired” state. So what you are seeing is the normal behavior.
I don’t understand by what you mean by “calls all return 0”. KeInitializeSpinLock does not return any value (its return type is void).
If you want to understand better, step over a call to KeAcquireSpinLock, and then check the contents of KSPIN_LOCK using a debugger. Again, never code any assumptions into a device driver about the contents of KSPIN_LOCK – the contents are private to the implementation, and could (potentially) change from release to release.
Also, bear in mind that the behavior on single-processor systems can be different from multi-processor systems. Spinlocks synchronize the execution of different processors. Dispatch levels synchronize the execution of different threads or interrupt sources on the same processor. So on a single-processor system, KeAcquireSpinLock is basically a no-op, because there are no other processors to synchronize with. I don’t know, off-hand, whether the single-processor HALs actually bother modifying the contents of the spinlock or not, but again, that’s just an implementation detail. The HAL provides the implementation of spin locks; ntoskrnl.exe just forwards the calls to the HAL.
Are you actually having a problem with spin locks, or is it just that you are surprised that the “initialized” state of a spinlock is “all zeroes”? If you’re having a problem, please describe what the problem is. Because unless you are corrupting memory, KeInitializeSpinLock “just works”.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@3dlights.de
Sent: Tuesday, November 21, 2006 7:45 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KeInitializeSpinLock returning zero
Hi folks,
I have a rather confusing problem. Im writing a MiniFilter Driver atm which worked quite well for some time, but after some changes I am stuck.
In my DriverEntry Function I do:
KeInitializeSpinLock( &MiniSpyData.PausePipeLock );
Now I was assuming that PausePipeLock should be != 0 after the call, but it always shows up as 0 in the kernel Debugger. I could not find any hint that this Function can go wrong, nor what the cause may be. Do you have any idear whats happening here ?
I could understand that the first spinlock is 0, but following KeInitializeSpinLock calls all return 0 ?!
Thx alot in advance,
Marcus
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer