1

I have a small DLL that hooks into the spooler on windows platforms. It hooks the StartDocPrinter function, with the result, that every time a print job hits the spooler my DLL is called. This DLL worked fine on all platforms before windows 8.

The DLL are also able to hook into the windows 8 spooler.

The DLL makes a TCP/IP connection to a service, that can run on the local machine or on a remote server.

The problem is:

On windows 8 there are two "desktops", the native Metro desktop and a Windows 7 alike desktop.

If the service runs on the same machine and I submit a print job from the Windows 7 alike desktop the print job enters the spooler, the DLL is called and is able to connect to the service, but if I submit a print job from the Metro desktop (f.ex. select print from the Internet explorer), the print job enters the spooler, the DLL is called but is not able to connect to the service and recieves an 10060 TCP/IP errorcode. If the service is on a remote server submitting print jobs from both desktops works fine.

When running the service locally, I have tried to use both 127.0.0.1 and the machines own IPV4 address, but the result is the same when submitting the print from the Metro desktop. I have tried to disable the firewalls, but that does not solve the issue.

Anyone who knows what could cause this behavior?

D Stanley
  • 149,601
  • 11
  • 178
  • 240
Ole Pedersen
  • 11
  • 3
  • Metro (Windows Store) apps are restricted by Windows from connecting to localhost. Maybe slightly different problem scenarios, but I think the answer is the same as this post: http://stackoverflow.com/questions/13410186/cant-use-streamsocket-to-connect-to-a-tcplistener/13410326#13410326 – chue x Jan 09 '13 at 15:09
  • Thanks for pointing me in the right direction, I totally missed the network isolation part of windows 8 :-( – Ole Pedersen Jan 10 '13 at 10:02
  • I have a few other observations that I would like to know if anybody knows the answer to. I have tested the current process name when my DLL is called and in both scenarios, I have found it to be "spoolsv.exe" as expected. In the DLL the loopback connections fails when the print is submitted from a Windows Store App. Another part of my solution is a port monitor, i.e. another DLL loaded by the spooler. This DLL also makes a loopback connection, and in this case it can make the connections even when the print job is from a Windows App. Anybody have an idea why the later case works ? – Ole Pedersen Jan 10 '13 at 11:32
  • That's an interesting one, I'm not sure why that would work. To get the most exposure, you really should ask a completely new question (and maybe provide more detail). If you found the answer in the linked question above useful, please upvote the answer here: http://stackoverflow.com/questions/13410186/cant-use-streamsocket-to-connect-to-a-tcplistener/13410326#13410326. Thanks. – chue x Jan 10 '13 at 15:04

0 Answers0