Hi. I am currently upgrading a 32-bit driver for a parallel adapter (a device that connects to the parallel port) to Microsoft Vista x64. It is a legacy, non-pnp driver. I have been able to compile the code without error for x64 platforms with the current WDK 6000. The driver works fine under 64-bit Windows XP, but I can’t get the same driver to load under Microsoft Vista x64. (By the way, the same code compiles/load/runs under x86 Vista as well). I keep getting a BSOD bugcheck of REFERENCE_BY_POINTER error during the boot process. I still suspect a driver load problem… Is there a way to only load a driver when it is first needed (not during boot or system initialization)?
Things I’ve tried:
- Test signing the x64 driver (embedded signature in the .sys file) and putting x64 Vista into test mode.
- Changing driver load order (as my driver contacts parport.sys to get the base port address of the parallel ports).
Any suggestions out there?
What is the output of !analyze -v when you get the bugcheck?
d
Well, you could set the start type to 3 (manual). But this is not
necessary…just use a serial attached WinDbg, setup symbols and post output
of !analyze -v here.
Have you tried to compile with 64-bit portability issues (/Wp64)? May be you
are truncating some pointer.
wrote news:xxxxx@ntdev…
> Hi. I am currently upgrading a 32-bit driver for a parallel adapter (a
> device that connects to the parallel port) to Microsoft Vista x64. It is
> a legacy, non-pnp driver. I have been able to compile the code without
> error for x64 platforms with the current WDK 6000. The driver works fine
> under 64-bit Windows XP, but I can’t get the same driver to load under
> Microsoft Vista x64. (By the way, the same code compiles/load/runs under
> x86 Vista as well). I keep getting a BSOD bugcheck of
> REFERENCE_BY_POINTER error during the boot process. I still suspect a
> driver load problem… Is there a way to only load a driver when it is
> first needed (not during boot or system initialization)?
>
>
> Things I’ve tried:
> 1) Test signing the x64 driver (embedded signature in the .sys file) and
> putting x64 Vista into test mode.
> 2) Changing driver load order (as my driver contacts parport.sys to get
> the base port address of the parallel ports).
>
>
> Any suggestions out there?
>
Hi. Thanks Doron and Frank. I will try out WinDbg on Monday as I’m away from my Vista testbox (with parallel port) this weekend and post the output. In the past, I’ve only used DebugView from SysInternals (I’ve had the luck not to have to dig any deeper into kernel debugging tools), so I’ll be a newbie at it 
So, is there a good “Getting Started” guide for WinDbg somewhere?
Thanks Doron and Frank. I will try your suggestions on Monday as I’m away from my Vista test machine for the weekend. Unfortunately, I haven’t used Microsoft’s kernel debugging tools (WinDbg). Any suggestions for a newbie looking for a good “Getting Started” website or tutorial for WinDbg?
Hi. It took me longer than I expected to get my WinDbg setup working through Firewire (Host: Vista x86, Target Vista x64), but now that it is running, here’s my “!analyze -v” printout. Let me know if you have any ideas…
–Brian Hindman
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
REFERENCE_BY_POINTER (18)
Arguments:
Arg1: 0000000000060002, Object type of the object whose reference count is being lowered
Arg2: fffff9800080d610, Object whose reference count is being lowered
Arg3: 0000000000000002, Reserved
Arg4: ffffffffffffffff, Reserved
The reference count of an object is illegal for the current state of the object.
Each time a driver uses a pointer to an object the driver calls a kernel routine
to increment the reference count of the object. When the driver is done with the
pointer the driver calls another kernel routine to decrement the reference count.
Drivers must match calls to the increment and decrement routines. This bugcheck
can occur because an object’s reference count goes to zero while there are still
open handles to the object, in which case the fourth parameter indicates the number
of opened handles. It may also occur when the object’s reference count drops below zero
whether or not there are open handles to the object, and in that case the fourth parameter
contains the actual value of the pointer references count.
Debugging Details:
DEFAULT_BUCKET_ID: VISTA_RC
BUGCHECK_STR: 0x18
PROCESS_NAME: System
CURRENT_IRQL: 2
LAST_CONTROL_TRANSFER: from fffff800018e5332 to fffff800018479a0
STACK_TEXT:
fffff9800080cdf8 fffff800018e5332 : 0000000000000000 0000000000000001 0000000000000065 fffff800018059e0 : nt!RtlpBreakWithStatusInstruction
fffff9800080ce00 fffff800018e758e : fffffa8000000003 fffff9800080e000 fffff800018a0480 0000000000000018 : nt!KiBugCheckDebugBreak+0x12
fffff9800080ce60 fffff8000184e354 : fffff9800080d4b8 fffff9800080d610 fffffa8003a83240 fffff80001a84cba : nt!KeBugCheck2+0x5ee
fffff9800080d4a0 fffff80001859eec : 0000000000000018 0000000000060002 fffff9800080d610 0000000000000002 : nt!KeBugCheckEx+0x104
fffff9800080d4e0 fffff980015a5260 : ffffffff800002ac 0000000000000108 0000000000000108 fffff8000189ff60 : nt!ObfDereferenceObject+0x23c
fffff9800080d550 fffff80001b6a142 : fffffa8000000000 fffffa80035fb750 0000000020206f49 0000000000000801 : DS1410D!DriverEntry+0x258 [c:\work\svnworkspace\ds1410d_driver\ds1410d.c @ 251]
fffff9800080d760 fffff80001c98beb : fffffa800309b478 fffff880007cb880 fffffa800309b3e0 fffff8800000001e : nt!IopLoadDriver+0x9e2
fffff9800080da30 fffff80001c9a507 : fffff80000000000 fffff880007cb880 0000000000000000 fffff880007b0200 : nt!IopInitializeSystemDrivers+0x23b
fffff9800080dae0 fffff80001c9b59b : ffffffff8000001c 0000000000000010 ffffffff8000001c fffffa8000c38960 : nt!IoInitSystem+0x7a4
fffff9800080dbb0 fffff80001bfe999 : 8c7ba7bfca000504 fffffa8000c58150 0000000000000080 fffff8000080e478 : nt!Phase1InitializationDiscard+0xec0
fffff9800080dd20 fffff80001ae199b : 55f97c4a82000524 fffff80001834b79 0000000000000010 0000000000000286 : nt!Phase1Initialization+0x9
fffff9800080dd50 fffff80001834b86 : fffff80001949880 fffffa8000c58150 fffff8000194eb80 fffff8000080e478 : nt!PspSystemThreadStartup+0x5b
fffff9800080dd80 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16
STACK_COMMAND: kb
FOLLOWUP_IP:
DS1410D!DriverEntry+258 [c:\work\svnworkspace\ds1410d_driver\ds1410d.c @ 251]
fffff980`015a5260 488d8c24c8000000 lea rcx,[rsp+0C8h]
FAULTING_SOURCE_CODE:
247: ObReferenceObjectByPointer( &ParPortDeviceObject,FILE_READ_ATTRIBUTES,
248: NULL,KernelMode);
249: ObDereferenceObject(&ParPortFileObject);
250:
251: KeInitializeEvent(&event, NotificationEvent, FALSE);
252:
253: // Make our i/o request packet (IRP) for a specific parallel port device
254: // and return PARALLEL_PORT_INFORMATION
255: irp = IoBuildDeviceIoControlRequest(
256: IOCTL_INTERNAL_GET_PARALLEL_PORT_INFO,
SYMBOL_STACK_INDEX: 5
SYMBOL_NAME: DS1410D!DriverEntry+258
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: DS1410D
IMAGE_NAME: DS1410D.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 45c8b3b7
FAILURE_BUCKET_ID: X64_0x18_DS1410D!DriverEntry+258
BUCKET_ID: X64_0x18_DS1410D!DriverEntry+258
Followup: MachineOwner
You should run Prefast for drivers against your source. You are passing the wrong address to ObDerefernceObject. ObDereferenceObject(&ParPortFileObject); should be ObDereferenceObject(ParPortFileObject);
d
Woohoo! Thanks Doron. Worked nicely! It took awhile for me to figure out test signing, but no more blue screens. We should now have a nice (and more stable) parallel port driver working under x64 and x86 Vista OSes…
If you are ever in Dallas, I owe you a dinner!