I have manifest-based ETW providers written in C++ and C#. Both providers use same manifest (generated by Microsoft.Diagnostics.Tracing.TraceEvent package from C# code). Channel is Debug.
Event publishing is success (return value is 0) in both providers and I can see them in perfview.
If manifest isn't installed, C++ provider's events are shown in perfview with provider's GUID, event id, etc. There is no "stringed" property like provider name, event name.
But C# provider's events have those properties.
Why C# provider can do this? In EventSource.cs, there is SendManifest method and additional ManifestData event is logged only when I use C# provider. Is this a reason? If so, can C++ provider achieve this behavior?
Edit
I know how to install manifest with wevtutil.exe or eventregister.exe. After some research, I found my necessary is implement "self-describing" event in C++.
The Windows 10 SDK includes support for a new ETW system that doesn't require a manifest at all. You can use the TraceLoggingProvider.h header to generate these events. This new system is also supported in .NET 4.6 or later in EventSource if you use the eventSource.Write method or if you set the manifest-free flag. (There is also an EventSource NuGet package if you want to use the new features but don't want to make .NET 4.6 a prerequisite for your program.)
Note that while the technology requires a new sdk, and you'll need new decoder tools to decide the new log file format, the technology works with programs running on Vista or later. In other words, you'll need to use the Windows 10 SDK to get the new TraceLoggingProvider.h header, but the resulting program will run ok on Vista or later as long as you set the WINVER macro to the right value for the OS you want to target.
The main benefit is that no manifest is needed. The main downside is that your log files will be a little bit larger (since each event needs to include a bit of information about how to decode itself).
The other answer is also correct and valid if you want to use manifest-based ETW. The only officially-supported system for manifest-based events is to register the manifest. The system that EventSource uses (where it throws a copy of the manifest into ETW) isn't well-documented, isn't supported by all of the ETW decoding tools, and I'm not sure that there's any support for you doing it yourself. If you're just interested in collecting and decoding log files, you only need to have the manifest registered on the machine where you'll be doing the decoding (the manifest is only used for merging and decoding -- it isn't needed when the log is being captured).
As far as I know TraceEvent emits the manifest during the rundown to the ETL stream which can then be decoded by WPA. Then WPA can display then the stringified name. If you let run both the C# and the C++ provider you should see one ETW provider with name. Personally I have worked around that by creating a manifest from my C# ETW provider and then registered it with in thy system with wevtutil. Then I always get a name but I need to have admin rights to do that.
See
http://etwcontroler.codeplex.com/SourceControl/latest#ETWControler/ETW/HookEvents.cs
Related
I need to create a custom installer to deploy a specific program. But there are a few checks and balances that needs take place during intallation, and even though I have an Advanced Installer license, it just struggles to do everything I need.
I'm looking for a way to create my own msi file using c#. Running the msi file it will then start a win forms wizard, which in turn will do a number of items, including copying files to the host PC.
I'm not sure how I can "include" my set of files into a single msi file. How to you "copy" files into an msi and how can you read again from it?
I can't even give a proper sample code of what I've tried as I don't know where to start.
This just feels like it should be a duplicate question, but I can't find it.
I work at Advanced Installer, since you said you already have a license let's help you get a return of investment on that ;)
First of all, I seriously doubt you need to reinvent the wheel and write your own code that installs/copies files on the machine. This is a basic action performed by all installer authoring tools, and even though it seems simple when you first think about it, it is not. You don't want to write code that handles rollbacks (if your install fails), reference counts (if a file is shared somehow), repair/self-healing operations (if somehow a DLL gets corrupted or missing post-install), or cover other standard Windows Installer scenarios.
Since you didn't explain with full details what you are trying to do I will give you some short example on how to do each of the steps you mentioned:
Adding files in a setup package - this is a link to a tutorial created with a free edition, but the same steps apply for Professional and Enterprise editions.
Searching files on a disk and retrieving values from them. - for this, you need to use the built-in support from Search page. There you can either simply search for a file and return its path or search for an element inside an INI or XML file and return its value inside a property.
Windows Installer properties are the equivalent of variables in your code. You can use them all over the installer project to pass/get/validate values.
Designing custom dialogs. Most professional installer authoring tools have support to build custom dialogs. The previous link is for a tutorial on how you can do that with Advanced Installer.
During the UI stages, you can include and custom C# code to perform additional validations or data retrieval operations and pass that to or from the installer using properties. if you need it.
The custom installer dialogs support is available starting with the Enterprise edition. The Professional and Free editions include the standard dialogs, but with no options to customize them.
Another way to interact with users is to design an UI experience inside your application that is visible only when the users launch the application for the first time. So, this is not a part of your installer. It will be code that you write inside your application and you can provide a first-launch experience similar to what you see when you install Office for example. If you can give me more details on what you want to do/capture in those custom dialogs, I will try to recommend you the best approach.
The recommended way to create an Application Event Log using wix seems to be
<Util:EventSource
Name="BLAH"
Log="Application"
EventMessageFile="[NETFRAMEWORK40FULLINSTALLROOTDIR]EventLogMessages.dll"/>
On 64bit OS you replace it NETFRAMEWORK40FULLINSTALLROOTDIR with NETFRAMEWORK40FULLINSTALLROOTDIR64.
I have noticed that when you run a 32bit app on a 64bit OS it creates an event log with NETFRAMEWORK40FULLINSTALLROOTDIR when your use the .NET EventLog.CreateEventSource method from code.
EventMessageFile => C:\Windows\Microsoft.NET\Framework\v4.0.30319\EventLogMessages.dll
If you run a 64bit version of the app with no eventlog it will create it so
EventMessageFile => C:\Windows\Microsoft.NET\Framework64\v4.0.30319\EventLogMessages.dll
Regardless of whether the EventMessageFile has Framework or Framework64 in the path both 32bit and 64bit versions of the app can write to it merrily once it is created.
Is this supported behavior? What is the correct way to create it if one were to allow both 32bit and 64bit versions of the app side by side ?
The Windows event log allows you to create localized event log message files. When Microsoft is writing a service that is part of Windows they probably want to be able to localize what is written to the event log. However, almost everybody else just wants to be able to write a string in their language of choice to the event log and that is exactly what the .NET event log wrapper provides. Thus .NET provides a very generic event log message file that contains no localized messages but just a message with a single argument placeholder where the supplied string argument is inserted giving you total control of what your .NET application writes to the event log.
I would be surprised if the 32 bit and the 64 bit default event log message files in .NET (EventLogMessages.dll) contained different messages but even with this knowledge you should point your 32 bit service to the 32 bit DLL and the 64 bit service to the 64 bit DLL. And if I understand your question correctly that is exactly the behavior that your are seeing.
There are no real "side-by-side" issues with regard to the .NET event log message file. However, if you for some reason decide to create you own (perhaps localized) event log message file you could either install two copies of this file with the two services or you could share a copy you then install to %CommonProgramFiles%. However, not doing a side-by-side installation with two copies can cause problems down the road if one version is updated independently of the other.
I'm working on an installation and configuration application in C# for a project I'm working on, and I'm wondering what the best method of internally organising everything is.
Requirements:
Single executable for deployment, no other files bundled with it.
Has to support custom config steps on each panel, which contribute to a generated XML config file at the end.
Certain steps may be skipped based on certain choices made within the installer flow.
Must support dynamic config screens based on information fed back from classes in one of my libraries.
Here's a description of my prototype:
A large form with a bunch of Panel controls, each representing one "screen" of the wizard. Each is named appropriately.
A class for each "screen", deriving from a base type I defined. I call specific methods of it (e.g. Enter, Back, Forward) when certain events occur.
State is stored as a Dictionary<string,object>, which is passed to each screen. The final screen (the actual "Installing..." screen) reads config out of this and dumps it into the XML file.
Each screen's code is responsible for handling the "Next" and "Prev" buttons, so I can control where it jumps to based on settings in the current screen.
A number of modules are stored in my library which provide information about extra config steps that need to be taken. I'm implementing this through reflection and automated UI generation.
Assets are stored in the resources of the executable.
I don't want to use a generic installer package (e.g. InstallShield) because the logic is totally custom and calls upon one of my class libraries. What I would like to know is - am I setting this out in a really circuitous way? Is there a simpler or more standard way to wizard-style applications?
Here's the short answer:
A commercial tool is perfect for what you need because it supports both custom installation UI and dynamic XML files. Anything else requires a lot of learning and hard work.
And the long explanation:
A custom installation UI is not an easy task. Windows Installer offers built-in dialogs and controls, so it's usually the best solution. You could also try a proprietary installation engine, but you will need to learn it.
You're also taking an incorrect approach by trying to control everything with custom code and classes. Most setup authoring tools offer direct support for handling the installation UI and XML files. Why try reinventing the wheel?
So you basically need to find the setup authoring tool which is best for you. Here is a general list:
http://en.wikipedia.org/wiki/List_of_installation_software
The tools are either MSI-based or proprietary. Personally I prefer Windows Installer (MSI packages).
Trying to implement all your tasks with custom code is just not worth it.
The only proper way to install software on Windows (which I assume is your target platform) is using Windows Installer. Simplifying a bit Windows Installer is based on the concept of a installation package (a database file) that in a transactional way can be added or removed from the system.
If you write your own installation logic you will not be able to participate in the transactional handling of software installation. If your uninstaller gets deleted there is no way the user can uninstall your software. Also, Windows Installer knows A LOT about the quirks of Windows which you may not be aware of.
Windows Installer provides a somewhat cryptic API for creating packages but you can also use then open source WiX toolset which is quite powerful or any commercial installer like InstallShield.
If you decide to go the Windows Installer way you should try to avoid custom actions if possible. Custom actions suffer from the same "transaction rollback" problem as a custom installer. You create the code for the custom action rollback/uninstall say in a DLL and if that DLL is lost there is no way Windows Installer can undo your custom action.
Windows Installer is actually quite powerful. You havn't given any specific information about the "custom stuff" you need to do but perhaps Windows Installer already has a table for that?
Use InstallShield or the MSI installer. Seriously. In addition to being able to support all kinds of custom logic (including code you specify), the generic installer wizards do things you're not even thinking about, like, say, listing the installed app in Programs and Features, and performing repair installs/uninstalls.
With the level of custom logic you're looking at, I would fork out for the latest InstallShield installer builder; the VS Install project builds into a pretty simple dialog set.
EDIT: Fair enough, been in that position before.
I would still HIGHLY recommend using any generic installer tools you have available, like VS's Install project, for the reasons I stated above; the install packages do things you aren't even thinking about in your design, and you get all of it for free.
Instead of putting this logic to customize your XML config file in the installer, how about putting it in your executable, as a "run-once" configuration wizard that the user will see when they start the application after installing it? It shouldn't be too off-putting to your users, and it should work well if the actual application is also a WinForms app (even if it isn't; you could compile the configurator into a different app and have your main app launch the configurator if it doesn't have an XML file).
Single executable for deployment, no other files bundled with it.
This might of some interest to you : http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx
Which user-mode functions in Windows 7 can I hook to monitor/intercept file access?
I've tried ntdll.dll's NtOpenFile(), NtCreateFile(), but some of these aren't files - they're also pipes and mutexes. Same goes for kernel32.dll's CreateFile(). Is there a function that is called only to access files/directories. If it helps, I'm trying to only hook explorer.exe to prevent access to firefox.exe. I'm also using EasyHook, if any of you have familiarity with it.
I think I've also read somewhere that, using the parameters from NtOpenFile/NtCreateFile, you can distinguish between file access/pipe access. But that's still a bit hazy. Is there a nice comfortable function to hook?
EDIT: Please keep in mind I do need to intercept file access to prevent access to some files. EasyHook is a great solution, since it allows me to perform complicated hooking in a few easy steps in C# managed code.
There is no "file open function" that only opens files. Furthermore, hooking is only supported using Detours. Finally, you must ensure that all computers running this have .NET 4.0 installed, so they can run in-proc SxS.
A far superior solution is to change the file permissions on firefox.exe. This is a solution that requires no licensing of Detours, and is supported.
I'm attempting to write a custom uninstaller script; however, I'm stuck at the "programs, and features" dialog. Are there any written documentation as to what registry keys do I need to add in order for my application to be displayed there? Or -alternatively- are there any native WINAPI / .NET functions to create a shurtcut there directly?
Addendum: there are business requirements disallowing me the use of third-party tools, such as the default MSI installer. Provided answer should work on a clean XP virtual machine, w/ .NET 2.0 installed, without referencing to any external .dlls. Thank you.
I would imagine MSI installer is the best solution, but if you must, the registry key which is the source of items in add/remove programs dialog is here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
I don't know if there's a good documentation about structure of this key, but I'm sure you can figure it out, it's not so hard