I have setup the registry for the Audio card "Creative SB! Live " with the audio driver "kx.sys" from www.kxproject.com
The driver starts to load but fails to initialize the SB card with the following debug messages
Any idea ? Is it possible to implement the function "_audddrvm" in ntoskrnl ?
--------------------------------------------------------------------- DriverBase for \SystemRoot\system32\drivers\kx.sys: dce72000 DriverBase for \SystemRoot\system32\drivers\portcls.sys: dcf2f000 (ldr/loader.c:1476) LdrPEGetExportByName(): failed to find _aulldvrm (ldr/loader.c:1561) Failed to import _aulldvrm from ntoskrnl.exe (ldr/loader.c:373) Could not process module (ldr/loader.c:319) Could not open module file: \SystemRoot\system32\portcls.sys (ldr/loader.c:1323) Unknown import module: portcls.sys (Status c0000034) (ldr/loader.c:373) Could not process module (io/pnpmgr.c:1518) Initialization of service emu10kx failed (Status c0000034) (io/pnpmgr.c:1452) IopActionInitChildServices(ccc26b60, ccc48ef8, 0) ----------------------------------------------------------------------
Best regards Gerard
Hi _aulldvrm are not export / stub or implemnet in ntoskrnl. see
(ldr/loader.c:1476) LdrPEGetExportByName(): failed to find _aulldvrm (ldr/loader.c:1561) Failed to import _aulldvrm from ntoskrnl.exe
----- Original Message ----- From: "Gge" gerard.gatineau@laposte.net To: "ReactOS Development List" ros-dev@reactos.com Sent: Thursday, December 30, 2004 4:50 PM Subject: [ros-dev] Creative SB! Live audio card - driver loading problem
I have setup the registry for the Audio card "Creative SB! Live " with the audio driver "kx.sys" from www.kxproject.com
The driver starts to load but fails to initialize the SB card with the following debug messages
Any idea ? Is it possible to implement the function "_audddrvm" in ntoskrnl ?
DriverBase for \SystemRoot\system32\drivers\kx.sys: dce72000 DriverBase for \SystemRoot\system32\drivers\portcls.sys: dcf2f000 (ldr/loader.c:1476) LdrPEGetExportByName(): failed to find _aulldvrm (ldr/loader.c:1561) Failed to import _aulldvrm from ntoskrnl.exe (ldr/loader.c:373) Could not process module (ldr/loader.c:319) Could not open module file: \SystemRoot\system32\portcls.sys (ldr/loader.c:1323) Unknown import module: portcls.sys (Status c0000034) (ldr/loader.c:373) Could not process module (io/pnpmgr.c:1518) Initialization of service emu10kx failed (Status c0000034) (io/pnpmgr.c:1452) IopActionInitChildServices(ccc26b60, ccc48ef8, 0)
Best regards Gerard _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Magnus Olsen wrote:
_aulldvrm are not export / stub or implemnet in ntoskrnl. see
(ldr/loader.c:1476) LdrPEGetExportByName(): failed to find _aulldvrm (ldr/loader.c:1561) Failed to import _aulldvrm from ntoskrnl.exe
This is an __int64 compiler internal helper function from VC7; VC6 hasn't got a combined div and mul for unsigned (or signed for that matter) 64-bit integers. It was added starting with Windows XP. As the developers clearly doesn't want anyone using Windows 2000 or less to use it, are we perhaps committing to (possibly unwanted) work and complexity by adding support, ad-hoc, for individual XP- (and later-) only drivers?
On the other hand, this might just be ignorance of its developers that could be fixed by asking them to change the build (or their code) just the tiniest bit, and watch out for VC7-specific compiler-internal function references in the future.
Just thought I'd raise a flag.
/Mike
Mike Nordell wrote:
(ldr/loader.c:1476) LdrPEGetExportByName(): failed to find _aulldvrm (ldr/loader.c:1561) Failed to import _aulldvrm from ntoskrnl.exe
This is an __int64 compiler internal helper function from VC7; VC6 hasn't got a combined div and mul for unsigned (or signed for that matter) 64-bit integers. It was added starting with Windows XP. As the developers clearly doesn't want anyone using Windows 2000 or less to use it, are we perhaps committing to (possibly unwanted) work and complexity by adding support, ad-hoc, for individual XP- (and later-) only drivers?
On the other hand, this might just be ignorance of its developers that could be fixed by asking them to change the build (or their code) just the tiniest bit, and watch out for VC7-specific compiler-internal function references in the future.
I created the Bug #467
Regards Gerard
-
Gge -
Magnus Olsen -
Mike Nordell