InternetCrackUrl

[unknown]

Hi Folks,

bizarre...

InternetCrackUrl() is failing when called from a port monitor that I have
written but the same code works quite well in a console application that I
wrote to help diagnose this. (A port monitor is a user-extensible component
of the windows spooler and runs [I assume...] not in the context of the
user.)

So, what's happening? When I call InternetCrackUrl() from my console
process, it works just fine but when I call InternetCrackUrl() from my port
monitor, I see the URL_COMPONENTS structure remains unchanged and
GetLastError() reports 0x2EE6 which I can't decode. (When I remove high
order bits, on the assumption that these are "facility" encoding, I
eventually get to 0x6E6 which is an RPC error, and probably a red herring.)

Is this a linking problem? Probably not since other WININET functions
(InternetOpen(), InternetConnect(), HttpOpenRequest(), HttpSendRequest(),
InternetCloseHandle() to name a few) are working correctly and I can verify
there correct behavior from the access log of the http server.

Does anybody have any idea what is wrong or any suggestions for what I might
try to diagnose this?

Chris.

[Vladimir Scherbina]

Chris,

Can you tell us a bit more about your port monitor application? How is it
implemented? When does it run? Under what user, etc. Several wininet
functions does not work properly at the system startup, so it might be the
problem.
--
Vladimir

Post by unknown
Hi Folks,
bizarre...
InternetCrackUrl() is failing when called from a port monitor that I have
written but the same code works quite well in a console application that I
wrote to help diagnose this. (A port monitor is a user-extensible
component of the windows spooler and runs [I assume...] not in the context
of the user.)
So, what's happening? When I call InternetCrackUrl() from my console
process, it works just fine but when I call InternetCrackUrl() from my
port monitor, I see the URL_COMPONENTS structure remains unchanged and
GetLastError() reports 0x2EE6 which I can't decode. (When I remove high
order bits, on the assumption that these are "facility" encoding, I
eventually get to 0x6E6 which is an RPC error, and probably a red herring.)
Is this a linking problem? Probably not since other WININET functions
(InternetOpen(), InternetConnect(), HttpOpenRequest(), HttpSendRequest(),
InternetCloseHandle() to name a few) are working correctly and I can
verify there correct behavior from the access log of the http server.
Does anybody have any idea what is wrong or any suggestions for what I
might try to diagnose this?
Chris.