Page 1 of 1

Messages cannot be dispatched on Win 8.1 from 64bit host

PostPosted: Tue Jul 15, 2014 7:18 am
by ogiesen
I think I identified a problem but I'm not quite sure whether its source is in the Logger or in the Dispatcher so I'm posting here in the General forum.

The symptom is that no messages are logged, neither to file nor to the live viewer nor any other destinations. However, this only occurs when the logging app is 64bit and runs on Windows 8.1. The same app on Windows 7 works just fine (I currently couldn't verify whether this would occur with regular Windows 8 as well as I only have 8.1 machine available ATM). Also, the 32bit-compiled version also has no such problems on the same system.

I already went old school and placed OutputDebugString messages all over CodeSiteLogging.pas . Here's what appears to happen:

The SendMessage-call at the end of TCodeSiteCopyDataConnection.SendMessageToDispatcher apparently always returns 0. This leads to the logger class disabling itself at the end of TCodeSiteLogger.SendCodeSiteMsgDetails.

The dispatcher gets started alright if it isn't running already and AFAICT the handle determined by FindWindow in TCodeSiteCopyDataConnection.GetDispatcherWindow is valid and does indeed belong to the dispatcher process. It doesn't appear to make a difference whether the user running the app has admin privileges or not. The Dispatcher log does not display anything out of the ordinary, i.e. the log is identical to scenarios where logging works as expected:

Code: Select all
Info   Dispatcher has been started   15.07.2014   14:13:35.003
Info   Default Receiver Started   15.07.2014   14:13:35.013
Info   TCP Receiver Started   15.07.2014   14:13:35.031
Info   UDP Receiver Started   15.07.2014   14:13:35.035
Setting   Enabled;  UIMode=Unrestricted;  MonitoringPorts=3434,3435;  FolderVariables=0;  RestrictFolders=No;  Categories=0;  BlockedMessages=0;     15.07.2014   14:13:35.038
Info   Loading Saved Dispatch IDs (0): C:\Users\admin\AppData\Local\Raize\CodeSite\5.0\CSDispatchIDs.ini   15.07.2014   14:13:35.041


I'm currently compiling with Delphi XE3 using CodeSite 5.1.5. The app in question is actually a COM-DLL that gets loaded as an addin for Outlook 2013x64. If necessary, I can probably produce a simplified demo EXE as well.

Any ideas?

Cheers,

Oliver

Re: Messages cannot be dispatched on Win 8.1 from 64bit host

PostPosted: Tue Jul 15, 2014 12:09 pm
by Raize Support
Hi Oliver,

If you haven't already tried to reproduce the issue in a test project, I would definitely try that.

Also, I would also suggest calling CodeSiteManager.ConnectUsingTcp in your COM DLL sometime before you make your first CodeSite call. Let me know if this gets through. I suspect that Windows/Office is blocking the default message transport.

Ray

Re: Messages cannot be dispatched on Win 8.1 from 64bit host

PostPosted: Wed Jul 16, 2014 5:40 am
by ogiesen
Hi Ray,

thanks! You were right on both counts (of course ;) ):

1. A simplified test EXE logs without problems on the affected system.

2. Calling ConnectUsingTcp brings back the log messages for my addin.

Wouldn't it maybe make sense to have an (optional) automatic fallback? I have already implemented my own clunky version of such a thing simply to see if it would work (i.e. after the first message I check whether the logger has been disabled and if so I call ConnectUsingTcp, reenable the logger and send the message again) but something more "integrated" would obviously be preferable...

Otherwise, are there any drawbacks to the TCP method? I assume there's a reason why CodeSite defaults to another method?

Finally, if this is indeed caused by some sort of internal security mechanism, could you think of any reason why Windows/Office would be blocking these messages only in this specific scenario? Why only block messages from the 64bit host but not 32bit?

Cheers,

Oliver

Re: Messages cannot be dispatched on Win 8.1 from 64bit host

PostPosted: Thu Jul 17, 2014 12:50 am
by Raize Support
Hi Oliver,

Let me answer your follow-up questions in reverse order. As for why Windows/Office would be blocking the messages, I suspect that this has to do with the fact that 32-bit processes are rather isolated from Windows 64. They run in their own subsystem, have access to different "mapped" versions of the directory structure and registry, etc.

CodeSite defaults to wm_CopyData more for historical reasons than anything else. For many situations, wm_CopyData provides a very fast reliable method for IPC. Also, back in the day when CodeSite first supported connecting with TCP, many systems had firewalls that were not as adaptive as they are now and every time you rebuilt your project your firewall would kick-in when you went to run the app. These are not really issues in today's environment.

As for drawbacks to using TCP, the dispatcher needs to be running to "listen" for the incoming messages. This isn't really an issue when sending Tcp messages to the Dispatcher on the same machine, but can be an issue when sending messages to a remote machine. That is, the CodeSite Loggers cannot start the Dispatcher on the remote machine.

One of the things that we are considering for the next major release is that all IPC will be done with TCP and we won't have to deal with Windows blocking the wm_CopyData window message. So an optional "fallback" will probably not be needed.

Ray