Application works as console but not as service

NTDEV
21

That’s normal, due to no incoming messages. :slight_smile:

NEVER EVER do this in the ServiceMain or service control handler threads. They cannot block.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Thank you all for thoughts.
> I was debugging the service using debug prints and I found out that the execution stops after:
>
> while( GetMessage(&msg, NULL, 0, 0 ))
> {
> TranslateMessage(&msg);
> DispatchMessage(&msg);
> }
>
> Even this loop runs thrice and after that the execution stops as i don’t see any prints further. I am investigating that.
> Can anyone give some insight into what is happening here?
>
> Thanks!
>

22

Tim, I don’t know what do you mean by a “Hidden Window”?
I have SW_HIDE passed to my WinMain(), I wonder if this is what you mean by “Hidden Window”.
And Yes! I am calling WinMain from my ServiceMain() function after calling RegisterServiceCtrlHandler.

Thank you Joe, for telling me to put the message loop in the same thread where the needed window is created. It shown me the right path.

Thanks Maxim, for the Warning :wink:

Thank you all for your valuable suggestions!
The service app is up now!

23

> And Yes! I am calling WinMain from my ServiceMain() function after calling

Now the laws:

  1. windows (i.e. HWNDs) are per-thread and are owned by a thread. If some thread have called CreateWindow, then it is obliged to run a GetMessage loop. Mandatory. No exceptions.

  2. thread running GetMessage loop cannot block.

Forget about WaitForSingleObject there.

Also, forget about read() and similar calls of infinite time - i.e. from socket, COM port, USB pipe and so on. Reads from on-disk files are usually not in this category - their execution time is only based on disk perf and load, not on some external factors like “when the next byte from the Internet will arrive”.

In .NET 4.5 (and in WinRT), MS even invented the async/await paradigm to help some not-so-talented developers :slight_smile: to fulfil the Law #2.

On older technologies, you’re on your own fulfilling this rule.

  1. ServiceMain/init path and service control handler are called in a way they cannot block for a long time.

Actually, ServiceMain is called by the special thread started by ADVAPI32.DLL internally, while the Handler is called by your main() thread with the stack of StartServiceCtrlDispatcher/ScDispatcherLoop, but this is a minor detail.

Handler must return ASAP. Otherwise, SC will complain.

ServiceMain must call SetServiceStatus ASAP. Otherwise, SC will complain.

Later, when init path in ServiceMain is done and you have reported the service as started, you can use ServiceMain the same way as any other thread, SC is no more interested in it.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

24

Maxim,

Thanks a lot for sharing the laws. The first one is my favorite though!
I’ll keep all of these in mind from now.