For Windows CE developers:
MS has scarce documentation on Implementing an Event Tracking Library.
I have registered an Event Tracking Library (as per the sample program in %_WINCEROOT%\public\common\sdk\samples\CeLog\load). However, when attempting to run CeLogFlush.exe on the custom event tracking dll, the CeLogFlush application complains that a CeLog map was not found.
Does anybody know if the custom Event Tracking Library is responsible for creating the CELOG_DATAMAP_NAME (SYSTEM/CeLog Data) or does the kernel do it?
Related
I have implemented a background service that sends some data to server.
But the service is only triggered after the trigger is fired.
I want the service to fire immediately as and when its registered.
I have tried
DeviceTrigger
LocationTrigger
SystemTrigger(Internet available/Timezone-changed)
MaintenanceTrigger
TimeTrigger
but they all are fired when their conditions are met as documented. Does any one have any idea how to get this work, btw I'm on windows phone 8.1 and C++.
PS. I just want my service to get triggered as it is registered.
AFAIK you can’t do that directly. Microsoft is very strict about what background tasks can and cannot do because battery life depends on it.
There’s a workaround.
Move your server-sending functionality from your background service into a separate DLL. Call that DLL from both background service process, and the GUI process. If you need to, in that DLL you can guard shared resources with a named mutex or use any other IPC mechanism that works across processes.
What is the purpose and usings of shared services in prism ?
What things can make me think that I have to use shared services instead of EventAggegator?
Looking at EventAggregator from an event subscriber point of view, it's good for getting notified about certain events that occur in the application. This way you're performing an operation passively, i.e. whenever someone else publishes an event. You'd like to use EventAggregator when you need to react to something happening in your application.
On the other hand, with shared services you can actively perform operations and request data. For example, you could have a shared service that exposes a GetData() method, and you could resolve this service and ask for the data actively, any time you need it.
I don't know how other using it but I used it a lot for modularity of my app. For example in Silverlight application for security reasons only OpenFileDialog could return Stream to file. So I just build an IOpenFileService service and plugged it in constructor to any ViewModel that need to open a stream to file. It's also suitable for various Loggers and even Database layer.
Another useful part of services is that they could be build and tested independently from other modules. MEF/Unity will provide all the glue to insert ready objects inside constructor or properties of other objects.
And don't forget that the service class itself could use MEF/Unity magic and insert other services to itself.
And for EventAgregator: You code could became overloaded with various Event definitions very quickly. For example Resize event. On Silverlight app initialization the PRISM Region controls is slow process so the Regions was attached to VisualTree very late and somehow they missing the initial Resize event . I provided the internal Resize event for Region (via EventAgregator) and then another Resize event that each Region control will send to it's children to resize themselves to Region control boundaries. It's 2 Event classes just for Resize...
We have used both, but generally use shared services when the functionality is more than just a simple notification - we also use EventAgregator from within our services in some cases.
For example we have a service for scanning in documents :
public interface IDocumentScannerService
{
}
public class DocumentScannerService : IDocumentScannerService
{
}
This would be a pretty bad design to try and implement this with EventAggregator.
Short Version:
Are the event sources "Application" and "Application Error" always included in the Application Event Log? Are they available on new installations of Windows XP, Vista and Windows 7? Would it be really bad to use them instead of creating my own source (an impossibility for me)?
Long Version:
I have a ClickOnce application that is used by users without administrative privileges on their machines.
When I try to write to the Appliction Event Log, I get a security exception. (The Windows event logging infrastructure is trying to create me a new event source, and gets a security violation.)
So I would like to try reusing an existing event source. I have found a only two"generic-sounding" sources in the Application Event Log. Are these always part of a Windows installation, and would make a reasonable choice?
Application
Application Error
I am sure this is frowned upon, as I should distinguish my application using its own event source. But this is for infrequent fatal errors, which should be getting logged elsewhere by my code. I just want a really easy place to find them on a client machine in case it all goes wrong...
When I try to write to the Appliction Event Log, I get a security exception. (The Windows event logging infrastructure is trying to create me a new event source, and gets a security violation.)
I have just answered this here: Using EventLog in ClickOnce application
So I would like to try reusing an existing event source. I have found a only two"generic-sounding" sources in the Application Event Log. Are these always part of a Windows installation, and would make a reasonable choice?
It's really not wise to do this. Existing event sources will be used by either Windows applications, or by third party applications. If any of those are removed, or changed by something like a service pack or patch, your program will crash unless you have implemented exception handling to handle the exception gracefully, but then you wont have any event logging.
Also consider the work you may have to do to port your app to the next version of Windows. I suggest you will be making a rod for your own back.
In the answer I linked to, I suggested the best way to handle the problem, is to install your application using admin privs with the installer creating the source, or by creating a simple app that effectively does the same using the admin role.
The only thing else I can suggest is to always run your application in admin mode.
I created a service in Visual C++. Installed it using instsrv.exe and srvany.exe.
When I check at the Services applet in Control Panel, the service is registered. But when I want to start it, this message appears:
the service on Local Computer started and then stopped. Some service stop automatically if they have no work to do, for example the Performance logs and Alert Service.
I just have this code inside my OnStart function:
(void)system("C:\ReleaseExe\Example1Server.exe");
I my code correct? Or is there any other way to code it to make sure that the service can be in running state?
Assuming that exe you are starting up is actually your service, this is the wrong way to do it.
The Windows Service Control Manager (SCM) actually calls into your service's EXE via defined entry points - you need to provide the logic to do what your particular service needs in those entry points, including notifying the SCM of state changes in your service (STOPPED-> RUNNING, RUNNING->STOPPED, and so on).
Read the background info on MSDN, starting here, for clarification of what you must provide. Note that OnStart is specific to implementing Services in managed code, you won't be doing it that way in Visual C++. Perhaps C# would be an easier route?
we're shipping a shell extension dll (registered with regsvr32).
is there an easy way to get debug output from this dll from another application (so we can send these traces home when something is broken)?
any ideas? what's the easiest way to get logdata from the dll to another process?
If it's a shell extension DLL, then doesn't it run as the logged-in user, and can't it therefore write to a log file in some suitable directory on disk? If so why then would you want it to write to another process?
You can use Event Tracing for Windows (ETW) to trace your extension DLL execution. ETW has almost no overhead when no listener is active, so in normal conditions your DLL will incur no perf penalty; at the same time it allows for detailed output at various levels of details.
The way ETW works is when the APIs are called, they check if there is a listener subscribed to the traces from particular publisher and if no, nothing is generated. If there is a listener, only the traces to which the listener is subscribed are written to a memory-mapped file. Thus, only as much traces data is generated as requested.
ETW listeners can be activated at any time and the publisher does not have to be restarted. Also, ETW is not flavor bound and can be used in both debug and retail. Thus, if a customer of yours has a problem, you have to only send them the listener with instructions on how to run it and collect the info; you don't have to sent them an instrumented binary version. You can either write your own app that acts as a listener, or you can use the standard tracelog.exe and tracefmt.exe tools to get the traces written to a file.
To generate the necessary ETW code in your DLL, you can use the WPP preprocesor instead of directly using the ETW APIs.
Note: While all the links I post here are to the Windows Driver Kit documentation, ETW and WPP can be (and are heavily) used for regular user mode programs.