FaxStartPrintJob wont work on xp - 2nd season

  • Thread starter Thread starter Sam Jost
  • Start date Start date
S

Sam Jost

Straaaange!!!

Now I installed debug symbols so I can tell what the system is doing
right before failure:

To start I call FaxStartPrintJob() (which happens to be
_WinFaxStartPrintJobA@16, just like expected).
The first thing there is an unnamed call to 7225153F which seems to be
some kind of initialisation since every WinFax*-routine does call this
address first. And this Initialisation is the place where the error
occures:
The first thing it does is check if FXSAPI.dll is loaded and if it is
not (it aint in my case) it calls LoadLibrary to load it (success
there)
Then it loads function pointers from the routines in FXSAPI: FaxAbort,
FaxAccessCheck, FaxClose, [...], FaxPrintCoverPageA,
FaxPrintCoverPageW

so far so good. then it tries to load the address of
FaxRegisterServiceProviderW
and fails to do so.

Funny thing, if I cheat the return code to make him believe the load
call worked the rest of the calls does work nicely and he does send
the fax without problems.


well, I'd conclude that it does load the wrong faxapi.dll, and a quick
search does conclude I got two different kinds on my system:

Verzeichnis von C:\WINDOWS\system32
29.08.2002 14:00 443.392 fxsapi.dll

Verzeichnis von C:\WINDOWS\system32\spool\drivers\w32x86\3
26.03.2003 14:00 451.584 FXSAPI.DLL


Another check, the PrintSdi-Sample does load the older one out of the
windows-dir while my 'real' program does load the other one from the
spooler. And the new one seems to have 'FaxRegisterServiceProviderW'
replaced by 'FaxRegisterServiceProviderExW'.

'PrintSdi.exe': 'C:\WINDOWS\system32\fxsapi.dll'
'bmed.exe': 'C:\WINDOWS\system32\spool\drivers\w32x86\3\FXSAPI.DLL'

Why does it do that? And why is a second defunct fxsapi.dll sitting
there in the spooler dir? It seems the printer install of a network
fax put it there?


Where do I find information about this?

Sam
 
The file 'C:\WINDOWS\system32\spool\drivers\w32x86\3\FXSAPI.DLL' is in fact
copied when you add a printer connection to a remote Windows Server 2003 fax
printer. That is needed when you send faxes using this remote fax printer
connection.

And all your programs are supposed to load the FXSAPI.DLL from
C:\WINDOWS\system32. In case the directory
'C:\WINDOWS\system32\spool\drivers\w32x86\3\' appears before
C:\WINDOWS\System32 in %PATH% environment variable, then there are chances
for FXSAPI.DLL to be loaded from incorrect place. Please ensure this is not
the case with you.

One more thing you can try is to run your program by temporarily deleting
the FXSAPI.DLL present under spool directory and see what happens.
--
Raghavendra R
Microsoft Printing, Imaging and Fax Team
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.'

Sam Jost said:
Straaaange!!!

Now I installed debug symbols so I can tell what the system is doing
right before failure:

To start I call FaxStartPrintJob() (which happens to be
_WinFaxStartPrintJobA@16, just like expected).
The first thing there is an unnamed call to 7225153F which seems to be
some kind of initialisation since every WinFax*-routine does call this
address first. And this Initialisation is the place where the error
occures:
The first thing it does is check if FXSAPI.dll is loaded and if it is
not (it aint in my case) it calls LoadLibrary to load it (success
there)
Then it loads function pointers from the routines in FXSAPI: FaxAbort,
FaxAccessCheck, FaxClose, [...], FaxPrintCoverPageA,
FaxPrintCoverPageW

so far so good. then it tries to load the address of
FaxRegisterServiceProviderW
and fails to do so.

Funny thing, if I cheat the return code to make him believe the load
call worked the rest of the calls does work nicely and he does send
the fax without problems.


well, I'd conclude that it does load the wrong faxapi.dll, and a quick
search does conclude I got two different kinds on my system:

Verzeichnis von C:\WINDOWS\system32
29.08.2002 14:00 443.392 fxsapi.dll

Verzeichnis von C:\WINDOWS\system32\spool\drivers\w32x86\3
26.03.2003 14:00 451.584 FXSAPI.DLL


Another check, the PrintSdi-Sample does load the older one out of the
windows-dir while my 'real' program does load the other one from the
spooler. And the new one seems to have 'FaxRegisterServiceProviderW'
replaced by 'FaxRegisterServiceProviderExW'.

'PrintSdi.exe': 'C:\WINDOWS\system32\fxsapi.dll'
'bmed.exe': 'C:\WINDOWS\system32\spool\drivers\w32x86\3\FXSAPI.DLL'

Why does it do that? And why is a second defunct fxsapi.dll sitting
there in the spooler dir? It seems the printer install of a network
fax put it there?


Where do I find information about this?

Sam
Click to expand...
 
Raghavendra R said:
The file 'C:\WINDOWS\system32\spool\drivers\w32x86\3\FXSAPI.DLL' is in fact
copied when you add a printer connection to a remote Windows Server 2003 fax
printer. That is needed when you send faxes using this remote fax printer
connection.
Click to expand...

well, yes, I try to send via this remote fax printer connection. And
it does work from the printsdi sample, even though it does not use the
ws2003 dll's but the one in the system32 dir.
And all your programs are supposed to load the FXSAPI.DLL from
C:\WINDOWS\system32. In case the directory
'C:\WINDOWS\system32\spool\drivers\w32x86\3\' appears before
C:\WINDOWS\System32 in %PATH% environment variable, then there are chances
for FXSAPI.DLL to be loaded from incorrect place. Please ensure this is not
the case with you.
Click to expand...

my %PATH% does not contain the spool dir at all. I'd guess the dll's
of the spool dir are being taken 'cause I enumerate the installed
printers so the user can choose one while in the printsdi sample it
just prints to a printer.
One more thing you can try is to run your program by temporarily deleting
the FXSAPI.DLL present under spool directory and see what happens.
Click to expand...

When I do that I get another error (126 - module not found).

With some more trial and error I found a way to reproduce the bug in
the printsdi sample:

When I call
OpenPrinter( printername, &printerHandle, 0);
DocumentProperties( hwnd, printerHandle, printername, 0, 0, 0);
before I call FaxStartPrintJob() it does load the wrong dll in the
DocumentProperties() call, and the whole thing goes bust.

I'm not sure, I think this might be an error in the fax handling. To
summarize:

if I call DocumentProperties before I call FaxStartPrintJob,
FaxStartPrintJob does fail.
If I dont call DocumentProperties it does work.

I'll try and wrestle my fax call free of the DocumentProperties, but
this all sounds like a bug to me.

thanks,
Sam
 
Back
Top