|
From: Brian H. <bh...@lu...> - 2007-09-05 00:02:50
|
Thanks.
Using these same parameters (those for compiling the .sys) sans the
inclusion of the -llibusbd, I get the same failure.
I am assuming that there is no windows reason that I have to put the files
into a dll, and have an rc, and def file and link to a ddl if my sample
driver is currently completely self contained.
I do get a warning about linking _DriverEntry@8 to _DriverEntry (and using
--enable-stdcall-fixup or --disable-stdcall-fixup). Not sure if there is
anything valuable in that warning.
I do get a minidump which shows the problem. If I am posting to the wrong
forum, please let me know. Maybe this is more a windows issue and less a
mingw issue. the exception seems to be a null pointer dereference by ntoskrnl.
If it helps: here is the sample code that sets and AddDevice...if it is me
not setting something right...not sure what it is. I haven't been able to
locate where the debug output of something like this might go. if someone
can point me in the right direction to research i would appreciate it.
For background, I built the full toaster package and installed the native
one. and at this point, am just attempting to replace the native
toaster.sys with my toaster.sys.
NTSTATUS
DriverEntry(
__in PDRIVER_OBJECT DriverObject,
__in PUNICODE_STRING RegistryPath
)
{
ToasterDebugPrint(TRACE, "Entered DriverEntry of "_DRIVER_NAME_" version "
"built on " __DATE__" at "__TIME__
"\n");
DriverObject->DriverExtension->AddDevice = ToasterAddDevice;
DriverObject->DriverUnload = ToasterUnload;
DriverObject->MajorFunction[IRP_MJ_PNP] = ToasterDispatchPnp;
DriverObject->MajorFunction[IRP_MJ_POWER] = ToasterDispatchPower;
DriverObject->MajorFunction[IRP_MJ_SYSTEM_CONTROL] = ToasterSystemControl;
return STATUS_SUCCESS;
}
Arg1: c0000005, The exception code that was not handled
Arg2: 805c8bf0, The address that the exception occurred at
Arg3: f996f848, Exception Record Address
Arg4: f996f544, Context Record Address
Debugging Details:
------------------
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced
memory at "0x%08lx". The memory could not be "%s".
FAULTING_IP:
nt!PipCallDriverAddDeviceQueryRoutine+39f
805c8bf0 8b03 mov eax,dword ptr [ebx]
EXCEPTION_RECORD: f996f848 -- (.exr 0xfffffffff996f848)
ExceptionAddress: 805c8bf0 (nt!PipCallDriverAddDeviceQueryRoutine+0x0000039f)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000000
Attempt to read from address 00000000
CONTEXT: f996f544 -- (.cxr 0xfffffffff996f544)
eax=ffb73800 ebx=00000000 ecx=ffb73958 edx=00000002 esi=c000035f edi=ffb738b0
eip=805c8bf0 esp=f996f910 ebp=f996f93c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!PipCallDriverAddDeviceQueryRoutine+0x39f:
805c8bf0 8b03 mov eax,dword ptr [ebx] ds:0023:00000000=????????
Resetting default scope
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced
memo
ry at "0x%08lx". The memory could not be "%s".
READ_ADDRESS: 00000000
BUGCHECK_STR: 0x7E
DEFAULT_BUCKET_ID: NULL_DEREFERENCE
LOCK_ADDRESS: 80558b60 -- (!locks 80558b60)
Resource @ nt!PiEngineLock (0x80558b60) Available
WARNING: SystemResourcesList->Flink chain invalid. Resource may be
corrupted, or
already deleted.
WARNING: SystemResourcesList->Blink chain invalid. Resource may be
corrupted, or
already deleted.
1 total locks
PNP_TRIAGE:
Lock address : 0x80558b60
Thread Count : 0
Thread address: 0x00000000
Thread wait : 0x0
LAST_CONTROL_TRANSFER: from 80591ce3 to 805c8bf0
STACK_TEXT:
f996f93c 80591ce3 e1cf5be8 00000001 800009ec
nt!PipCallDriverAddDeviceQueryRouti
ne+0x39f
f996f988 80592434 f996fa14 e1cf5bd4 f996f9e8
nt!RtlpCallQueryRegistryRoutine+0x3
b1
f996f9ec 805addac 00000000 00000084 00000001 nt!RtlQueryRegistryValues+0x2a6
f996fac0 805adead 00000000 00000001 f996fd54 nt!PipCallDriverAddDevice+0x261
f996fd1c 8061ab9f ffbbfd30 00000001 00000000 nt!PipProcessDevNodeTree+0x1a4
f996fd4c 8050cdff 00000003 80558c40 80561b7c nt!PiRestartDevice+0x80
f996fd74 804e47fe 00000000 00000000 8133f3c8 nt!PipDeviceActionWorker+0x15e
f996fdac 8057dfed 00000000 00000000 00000000 nt!ExpWorkerThread+0x100
f996fddc 804fa477 804e4729 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
nt!PipCallDriverAddDeviceQueryRoutine+39f
805c8bf0 8b03 mov eax,dword ptr [ebx]
SYMBOL_STACK_INDEX: 0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntoskrnl.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 41108004
SYMBOL_NAME: nt!PipCallDriverAddDeviceQueryRoutine+39f
STACK_COMMAND: .cxr 0xfffffffff996f544 ; kb
FAILURE_BUCKET_ID: 0x7E_nt!PipCallDriverAddDeviceQueryRoutine+39f
BUCKET_ID: 0x7E_nt!PipCallDriverAddDeviceQueryRoutine+39f
At 05:13 AM 9/1/2007, Cesar Strauss wrote:
>Brian Hawley wrote:
> >
> > I'm slowly making progress on getting the new environment setup for
> > building drivers using mingw and msys.
> >
>
>[...]
>
> > I don't intend to build the entire DDK, I'm just looking to validate
> that a
> > driver built with mingw acts the same as when build with 'build' of the
> DDK.
> >
>
>Hi Brian,
>
>You may want to take a look at the libusb-win32 project:
>http://sourceforge.net/projects/libusb-win32/
>
>It contains a USB device driver built with MinGW. I suggest looking at
>their makefiles for the compilation switches they used, and at the
>source code for guidance in writing a Windows device driver.
>
>As the libusb-win32 driver code is GPL'd, however, you must be prepared
>to license your own code under the same terms, if you ever distribute
>your derived work.
>
>Regards,
>Cesar
>
|