We are attempting to use the Skype API (1.4 Windows) from within our application which runs as a Windows Service (ran with the SYSTEM account privileges). For some reason, the DISCOVER/ATTACH steps do not work. We can register the messages, and send the discover, but we never get the attach message back. If we run our application under a normal user account, the attach message comes back and everything operates normally. Anyone experienced anything similar?

Thanks,
Michael

[quote=Michael Price]We are attempting to use the Skype API (1.4 Windows) from within our application which runs as a Windows Service (ran with the SYSTEM account privileges). For some reason, the DISCOVER/ATTACH steps do not work. We can register the messages, and send the discover, but we never get the attach message back. If we run our application under a normal user account, the attach message comes back and everything operates normally. Anyone experienced anything similar?

Thanks,
Michael[/quote]

This isn't a bug. If anything, its a flaw in the design of the Skype API.

Since it relies on Windows Messages, the app and Skype *must* be operating in the same Windows desktop. The "SYSTEM" user has its own Desktop, thus it cannot share Windows messages with Skype running as a different user.

Both Skype and your service must be running as the same Windows user.

[quote=granger]
Since it relies on Windows Messages, the app and Skype *must* be operating in the same Windows desktop. The "SYSTEM" user has its own Desktop, thus it cannot share Windows messages with Skype running as a different user.

Both Skype and your service must be running as the same Windows user.[/quote]

If I have to use Skype API with a window application there are not problems, but if I have to use the API with a web application?
I'm trying with an ASP.net page but I'm not able to use Skype API because my app don't attach to Skype. Can you help me please?

[quote]You can also broadcast messages to all top-level windows by specifying HWND_BROADCAST in the SendMessage, SendMessageCallback, SendMessageTimeout, or SendNotifyMessage function.

Applications receive messages through the window procedure of their top-level windows. Messages are not sent to child windows. Services can receive messages through a window procedure or their service control handlers.[/quote]

Please make a new topic!

[quote=Michael Price][quote]You can also broadcast messages to all top-level windows by specifying HWND_BROADCAST in the SendMessage, SendMessageCallback, SendMessageTimeout, or SendNotifyMessage function.

Applications receive messages through the window procedure of their top-level windows. Messages are not sent to child windows. Services can receive messages through a window procedure or their service control handlers.[/quote]

Please make a new topic![/quote]

I don't understand what you mean by "Please make a new topic!"

At any rate, that quote is correct. Services *can* receive messages. But Skype running as SYSTEM will not receive Windows messages from another 'desktop'. Its basic Windows Internals.

You can run Skype under the same user as your service, or you can run your service under the same user as Skype.

[quote]I don't understand what you mean by "Please make a new topic!"[/quote]

Sorry, I quoted the wrong text (I had copied some stuff from MSDN for an email to a colleague!) That quote was meant to be:

[quote]If I have to use Skype API with a window application there are not problems, but if I have to use the API with a web application?
I'm trying with an ASP.net page but I'm not able to use Skype API because my app don't attach to Skype. Can you help me please?[/quote]

Any matter,

If a service is marked as "interactive", shouldn't it receive messages that are broadcast to top-level windows?

Thanks,
Michael

[quote=Michael Price][quote]I don't understand what you mean by "Please make a new topic!"[/quote]

Sorry, I quoted the wrong text (I had copied some stuff from MSDN for an email to a colleague!) That quote was meant to be:

[quote]If I have to use Skype API with a window application there are not problems, but if I have to use the API with a web application?
I'm trying with an ASP.net page but I'm not able to use Skype API because my app don't attach to Skype. Can you help me please?[/quote]

Any matter,

If a service is marked as "interactive", shouldn't it receive messages that are broadcast to top-level windows?

Thanks,
Michael[/quote]

Yes, if service is marked as interactive it is moved to the current user's desktop. In that case, I believe it will receive Windows messages appropriately.

So, I guess more appropriately the two must be in the same Desktop.

[quote=Michael Price]
Sorry, I quoted the wrong text (I had copied some stuff from MSDN for an email to a colleague!) That quote was meant to be:

[quote]If I have to use Skype API with a window application there are not problems, but if I have to use the API with a web application?
I'm trying with an ASP.net page but I'm not able to use Skype API because my app don't attach to Skype. Can you help me please?[/quote]
[/quote]

Sorry.

[quote]
Any matter,

If a service is marked as "interactive", shouldn't it receive messages that are broadcast to top-level windows?

Thanks,
Michael[/quote]

Thaks! Only another question... :wink:
When I debug an ASP.NET page with VisualStudio.net, the web application is executed by ASPNET user, while my Skype client under my personal user. How I can resolve this problem in debug step?
Sorry again. :roll:

[quote]Thaks! Only another question... Wink
When I debug an ASP.NET page with VisualStudio.net, the web application is executed by ASPNET user, while my Skype client under my personal user. How I can resolve this problem in debug step?
Sorry again. Rolling Eyes[/quote]

For G-d sake man, don't you understand what START ANOTHER TOPIC means? Maybe I'm being a protocol freak here, but piggybacking off another person's post for something largely unrelated is annoying as hell.

So as a test, I set up our environment as before, Skype running as the locally logged on user, our App running as an interactive service under the SYSTEM account.

I also opened up Spy++ to verify that messages were being received. The Skype window successfully received the SkypeControlAPIDiscover message, but it never responded back to our app with the SkypeControlAPIAttach message.

Our theory is that Skype might be attempting to access our process, and requesting a higher set of permissions than is needed (like PROCESS_ALL_ACCESS). Since our app is running as SYSTEM, the request by Skype is then denied, and Skype fails to handle the failure appropriately.

Any ideas?

[quote=Michael Price]So as a test, I set up our environment as before, Skype running as the locally logged on user, our App running as an interactive service under the SYSTEM account.

I also opened up Spy++ to verify that messages were being received. The Skype window successfully received the SkypeControlAPIDiscover message, but it never responded back to our app with the SkypeControlAPIAttach message.

Our theory is that Skype might be attempting to access our process, and requesting a higher set of permissions than is needed (like PROCESS_ALL_ACCESS). Since our app is running as SYSTEM, the request by Skype is then denied, and Skype fails to handle the failure appropriately.

Any ideas?[/quote]

Certainly possible. When an application tries to use Skype, Skype does some sort of hash on it to see if its allowed to access the Skype API. Presumably this requires the ability to read the process and/or executable in some way. Sounds like Skype is denying access for some reason or another (IIRC it doesn't tell you when it denies you access).

Something that I've seen happen in my efforts is sometimes Skype gets it in its head it should be denying something. Occasionally (to be safe), I go into:

C:Documents and SettingsuserApplication DataSkypeskypeuserconfig.xml

and you can delete everything between the <AccessControlList> tags. This will reset Skype's thoughts on what should and should not be allowed.

That may not be the problem, but I've had it happen often enough that I think its worth trying.

Good luck!

you can go to tools options privacy manage other programs access to skype to see what it has your program set too.

[quote=mscoville]you can go to tools options privacy manage other programs access to skype to see what it has your program set too.[/quote]

Probably a safer way to delete the entries.

Yeah, so removing the possibly-stale information about program access didn't resolve the issue. But hey, it was worth a shot.

Any Skype emplooyee-type-folk out there want to give it a shot? I noticed on another thread that an employee recognized a bug presented by a user. It would be great if we could know if this is a "bug", "design flaw", or a "feature"!

Thanks for all the help thus far granger and mscoville!

-- Michael

As another test, just to verify that it wasn't an issue with our code, I spawned off the msgapitest.exe (from the Skype provided example code for windows) from within our app (so that it would inherit its credentials) and the same symptom was experienced (verified with Spy++). Skype received the Discover message, but no Attach message was returned to the client.

Will this bug be fixed in 1.5, or is this really not a bug (I might be missing something)?

Thanks,
Michael

Are there any Skype employees who can shed light on this issue? I've been waiting for some response (even if it is, "We'll get back to you") for several weeks now.

The general problem is that you have to run your application on the same windows station as the Skype client. Only then you are able to connect to Skype API.

It is possible to run your app as service and connect it to Skype client. I have succsessfuly run my test script (VBscript and SkypeX) as Windows service using FireDaemon (http://www.firedaemon.com/). It was quite a long time ago, and I do not remember all the settings and options I had to use.

Whenever another application wants to connect to Skype Client via the API, Skype Client asks the user whether to grant this application access always, once, or never. For that purpose, Skype Client needs some information about the executable. If this information is unavailable or inacessible to Skype Client, the application will not be allowed to connect to Skype Client.

[quote]Whenever another application wants to connect to Skype Client via the API, Skype Client asks the user whether to grant this application access always, once, or never. For that purpose, Skype Client needs some information about the executable. If this information is unavailable or inacessible to Skype Client, the application will not be allowed to connect to Skype Client.[/quote]

Yes, I understand this. But the question is, what makes this "information" unavailable to the Skype Client. Our hypothesis is that the Skype Client is using the OpenProcess(...) function to get a handle to our application's process, which it then uses to get the "information" used to authenticate the application. The problem we could see would be that the Skype Client is requesting more access rights with the DWORD dwDesiredAccess param to the OpenProcess(...) function than is really needed to obtain the needed "information".

Example: Skype might be using the PROCESS_ALL_ACCESS flag for this param, which would be denied by OpenProcess due to the highly restrictive security descriptor of our process running as SYSTEM (in the interactive Desktop). Instead, perhaps Skype should use the PROCESS_QUERY_INFORMATION flag or the minimal combination of such flags that are required to obtain the needed information. Perhaps then, the OpenProcess function will not fail and we will get prompted for permission from the user.

Any thoughts?

By the way, thanks to ppmotskula for responding. We appreciate it!

Skype is designed to work with other programs sharing the same user environment (windows userid) so you might call this a feature. However I discussed the issue with our developers and they said they might take a look at your log files. If there is an easy solution, you'll get one. But I cannot and will not promise any immediate major architectural changes to Skype.

Michael, please skype me for instructions how to create the logs.

Did you send discover message (broadcast), by SendMasseage API?

If you use SendMessage API, deadLock by some window Proc of wrong process.

Pls use PostMessage API for broadcast!!

I have the same timeout problem of sending message to skype client in sharepoint just like what msn did.
Has this old problem been resolved? skype should be more open to extend market.

for temp solution, i'm planning to run a local socket listener on desktop to forward skype request from service. a little weired...

I've run into the same damn problem and due to the framework I'm using, I can't change the account of the service I'm using. Skype should add some service component to 'pick' up the API calls so Windows Services can use it!

Well I've finally solved this particular problem. Simply do the following to get your Windows Service communicating with Skype...

- Windows Control Panel
- Administrative Tools
- Services
- Find your Windows Service
- Right click and go to the Service's properties
- Go to the 'Log On' tab
- Select 'Allow service to interact with desktop'
- Click 'OK'
- Now restart the service
- Heh presto, it your service should now communicate ok with Skype!

There are changes with system services and session 0 ("The ability to interact with the desktop") in Vista please see this:

http://www.microsoft.com/whdc/system/vista/services.mspx