Error logging for Remote feature

[mmehr2]

Currently, TRACE statements will be used. I attempted to add AfxMessageBox() but it's ugly, needs more work. Better yet, implement a Status control on the main UI. For now, it can be added to the RemoteDialog. Just a static that can be updated with network status and a separate one for error messages. Allow multiline. Make it easy enough to read.

[mmehr2]

This should be added directly to the Remote Dialog box. Currently we have the ability to get error messages for both publish and subscribe issues. This is for user-readable errors.

A timestamped logging feature would be of more use to maintainers in debugging the more complicated issues. Steve seemed to have plans for this (based on libjingle's logging features) but I can find no evidence of this actually being used. Pubnub has similar features, but they use the std console streams by default. We would need to compile in a replacement printf-style function (I have included one) for use by the Pubnub library code, and then recompile the library from source. And make it capable of redirection to a log file or files, with size limiting and all similar features. Or use a good logging library in addition. No time has been allocated in this project for any of this.

[mmehr2]

When it comes to using tracing better in the runtime, the Windows Event Log actually provides a better feature set, and is more useful for this for reasons stated in this article, which also describes how to implement this for MFTrace (Media Foundation trace log), but could be useful for us too. https://blogs.msdn.microsoft.com/mf/2011/01/20/using-mftrace-to-trace-your-own-code/

[mmehr2]

There is a tie-in with the UUID issue (#11 ) of device IDs. This also requires a UUID. Typically this is done with guidgen (MS tool), but that is based on the ethernet card's Mac address. Some users don't like this, so pubnub provides their own. We would generate this and save it in the INI file (for example). See that issue for more info. [UPDATE: the saved UUID is now a feature of the ChannelInfo class.]

[mmehr2]

Turns out there are three main styles of event logging for Windows:

1. Old days: either Event Tracing for Windows or Event Logging

2. Vista+: ETW bare or via Windows Event Logging (old EL was deprecated)

3. Windows 10: TraceLogging introduced, works with legacy, requires VS2013+ though and Win10 SDK

It would be nice to use TL, but we need the ETW/WEL version with VS2010. Sigh. Requires an event manifest be compiled in to describe how to interpret the messages in the logger itself, which does the rendering outside our process.

Much complication down this path, but here's another article discussing the bare bones:

https://stackoverflow.com/questions/37035958/log-to-event-viewer-on-windows-with-c

This requires a fair amount of additions to the registry though, and some might need to be set up at startup time (path to EXE for example).

Events would all have to be rendered as a string before sending the event. But at least the startup could be sent by the Event Viewer properties instead of our code. Not sure how this works yet.

[mmehr2]

This represented two things, status reporting and error logging. The former is represented in issue #20 and the latter will be planned here.

[mmehr2]

Work tasks: UPDATE 4/2: With a better understanding, I can see value added here by doing the following.

• Design the most important events to log.

• [ ] -- State changes: login, logout, connect, disconnect.

• [ ] -- Configuration changes (device and company name, UUID (shouldn't), security, etc.)

• [ ] -- Also error message reporting (most value).

• [ ] -- Transaction (callback) logging event is also good (stats etc).

• [x] --- Basic level.

• [ ] --- Complete event log w stats.

• [ ] -- And performance events (time measurement tests, logs).

• Implementation steps

• [x] Generate a manifest to hold events using ECManGen, with output to MswEvents subfolder.

• [x] Compile the manifest with MC, compile the resources with RC (manual).

• [x] Include compiled output into DebugR project

• [x] Include compiled output into ReleaseR project

• [x] Test and make any changes.

• [x] Automate custom build steps for MC and RC in DebugR.

• [x] Copy custom build steps into ReleaseR.

• [ ] Add additional events as needed (verbose levels).

• Installation steps

• [x] Run manual install w.wevtutil on developer machines for testing (Win7, Win10).

• [ ] Generate installer script changes to do this on client (with Admin Privileges). Eric may want/need this to be done as a separate Debug installer, however.

It's important to include enough state change info and error results to allow for debugging in the field. Useful especially for file transfer cancels, other network error reporting, logging the transaction counts and timing, and the like.

[mmehr2]

I spent a few hours today trying to code up the manifest file needed by Windows Event Logging. It went fairly well, and I created and compiled the various resources. But then I noticed that installation requires the command line 'wevtutil im name.man' to be run at elevated privileges (as Admin). If this needed to be added to the install, it may trigger issues of customer acceptance (why do we need to run the install at a higher privilege now when we never used to?).

A possible solution to this is to provide a separate installer for the Event Manifest, and tell the customer what will happen when they do this (or they can execute the command themselves). Or we could just say it's required to patch in an event logger for debugging if there are any issues.

In any case, this is probably NOT going to be needed at ReadyCam until sometime later, at which they will need some debugging effort. No harm in using it for my own testing, and eventually deploying on demand at a customer site if it turns out debugging is required.

[mmehr2]

I got the event manifest system to install properly at least, from custom build steps in the project, to the final install statement executing without complaints.

The most useful article was here: https://blogs.msdn.microsoft.com/seealso/2011/06/08/use-this-not-this-logging-event-tracing/ In addition, manual installation would not have happened without this article: https://stackoverflow.com/questions/9216675/warning-provider-resources-not-accessible-running-wevtutil/32727624

I had to install the manifest manually as follows: C:...>icacls C:\Users\Mike\Documents\Toptal\ECSVideo\MSW\Msw4\DebugR\MagicScroll.exe /t /grant Everyone:R processed file: MagicScroll.exe Successfully processed 1 files; Failed processing 0 files C:...>icacls C:\Users\Mike\Documents\Toptal\ECSVideo\MSW\Msw4\ReleaseR\MagicScroll.exe /t /grant Everyone:R processed file: MagicScroll.exe Successfully processed 1 files; Failed processing 0 files C:...>icacls C:\Users\Mike\Documents\Toptal\ECSVideo\MSW\Msw4\EvtGen\MswEvents.man /t /grant Everyone:R processed file: ..\EvtGen\MswEvents.man Successfully processed 1 files; Failed processing 0 files C:...>wevtutil um C:\Users\Mike\Documents\Toptal\ECSVideo\MSW\Msw4\EvtGen\MswEvents.man C:...>wevtutil im C:\Users\Mike\Documents\Toptal\ECSVideo\MSW\Msw4\EvtGen\MswEvents.man /rf:C:\Users\Mike\Documents\Toptal\ECSVideo\MSW\Msw4\DebugR\MagicScroll.exe /mf:C:\Users\Mike\Documents\Toptal\ECSVideo\MSW\Msw4\DebugR\MagicScroll.exe OR C:...>wevtutil im C:\Users\Mike\Documents\Toptal\ECSVideo\MSW\Msw4\EvtGen\MswEvents.man /rf:C:\Users\Mike\Documents\Toptal\ECSVideo\MSW\Msw4\ReleaseR\MagicScroll.exe /mf:C:\Users\Mike\Documents\Toptal\ECSVideo\MSW\Msw4\ReleaseR\MagicScroll.exe C:...>

Test with this: wevtutil gp MagicScrollForWindows-Event-Provider wevtutil gl Msw-Events

Basically, I had to grant Read permission to everyone for both the manifest and the exe, and then I had to specify absolute paths to the manifest and provider in the install statement itself. This implies the user moving the EXE around could be a problem. :(

Once installed, you need to enable View > Show Analytic and Debug Logs Then find the log, right click it an Enable Log to enable the channel.