I have ETW tracing in a driver; the manifest file is created properly, the resources are all compiled in, etc. On the target machine, I run this command as administrator:
wevtutil im myManifest.xml
I get no errors. Then, I run (as administrator):
logman create trace myProviderName -o Log.etl -p "{myProviderGUID}" -f bincirc -max 1000
With no errors. Then I wait enough time for some traces to have been performed, and then I run these comands (as administrator):
logman stop myProviderName
tracerpt Log000001.etl
Now the problem I'm having is that the generated file, dumpfile.xml shows records of none of my traces at all. It shows a basic structure of setup details including the Provider GUID, etc.
So my question: Is there a step I'm missing in the above procedure, or must the problem be with my tracing code?
It turns out that there was a problem; though it wasn't with my code. I did not include opcodes for my events in the manifest, and as such, no events were being recorded.
If someone stumbles upon this post, it may help you to note that your events must have a channel, level, opcode, and template for even basic functionality. Additionally, the above procedure is missing one step. I needed to do the following:
Right click 'My Computer' and select 'Manage'
Click Performance > Data Collector Sets > User Defined > myProvider
Right click myProvider in right-hand pane, select 'Properties'
Set Keywords(Any), Keywords(All), and Level according to what I specified in the manifest
Restart my machine, and re-enable trace via logman.
The above procedure (in the question + the supplemental directly above) will create a log session and produce a basic readable log output from the generated ETL file.
Related
I have a .msi file created by Wix toolset, used to install 5 drivers. And I have a setup application to launch the .msi by CreateProcess with msiexec.exe command, and provide an UI. Currently, my requirement is get the detailed result of the installation – which drivers installed successfully, which failed. Since I can just get the result of CreateProcess, how can I retrieve the detailed result from the installation? Very appreciate if you can provide some information on this issue.
I created the .msi file with the difx:Driver flag like below:
<difx:Driver AddRemovePrograms="no" DeleteFiles="no" ForceInstall="no" Legacy="no" PlugAndPlayPrompt="no" />
An MSI-based setup is transactional. It either all works or all fails and rolls back the system to its previous state. It seems that you have made a choice to defeat this paradigm and have it partially succeed leaving some drivers installed and others not.
It also appears that you have suppressed the installer's UI so that error information cannot be found.
I have two recommendations:
Don't use CreateProcess() and the "fire and forget" model. Use MsiSetExternalUIRecord with this model:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb309215(v=vs.85).aspx
There are C# p/invoke equivalents out there too. If you don't want to show all the UI then just collect the error messages and show them to the user if that's the goal. That's the only reliable way to get the actual error messages. This is the supported way for you to own the UI and collect only the messages that you think are important.
Allow a failed driver install to fail the entire install and roll it all back. It might actually be like this already. If the install partially succeeds and four drivers are not installed, what's the plan? You can't run the MSI again because it will go into repair/maintenance mode. If the user needs to fix something and do the install again then the product needs to be uninstalled anyway.
You can retrieve the verbose installation log using the /L*V parameter:
msiexec /i "C:\MyPackage\Example.msi" /L*V "C:\log\example.log"
You can read more here.
The general structure is:
msiexec.exe [/i][/x] <path_to_package> [/L{i|w|e|a|r|u|c|m|o|p|v|x+|!|*}][/log]
/L - enable logging
i - include status messages
w - include non-fatal warnings
e - include all error messages
a - mention when an action is started
r - include action-specific records
u - include user requests
c - include the initial UI parameters
m - include out-of-memory or fatal exit information
o - include out-of-disk-space messages
p - include terminal properties
v - verbose output
x - include extra debugging information
+ - append to an existing log file
! - flush each line to the log
* - log all information, except for v and x options
Another simpler method, instead of parsing the log, would be to write a small C# custom action to check if the drivers are installed on the machine.
You need to schedule that custom action close the end of the installation process, as deferred (not immediate).
You can generate a log (as suggested by Harsh) or you can create a custom action (either deferred as suggested by Bogdan if you are using the method he suggests) or sequenced after InstallFinalize (if you have some other method that doesn't require elevation), but that custom action would probably need to use some sort of IPC to communicate what it finds back to your program.
One possibility for IPC might be the MsiProcessMessage function in your custom action with the INSTALLMESSAGE_INFO message type (what you send will also show up in the log) that you can receive in your application, but that will require using the MsiSetExternalUIRecord function which will require replacing your CreateProcess calling msiexec with something from the Installation and Configuration Functions section of that page.
Or if writing custom actions isn't where you need to go it may be easier for you to call MsiGetFeatureState or MsiGetComponentState with MsiOpenProduct, assuming that gives you the granularity of detail you're after.
I just started using the ms Detours library, and I would like to know how to hook an exe file using it. I got the function offset from IDA Pro, however i don't know what address should hook to. It gives a access violation if I hook to the offset using the withdll.exe tool. Could someone show me an example of hooking an exe if it is possible?
The StackHash crash happens because you are probably trying to execute code from the page that does not have EXECUTE access. You can disable DEP just to make sure this is the cause for the crash. Subsequently, if this is indeed the case, you should use VirtualProtect or VirtualProtectEx to modify the page protection using one of the protection constants that include EXECUTE access (you can see the list of the constants here). As per the address/offset calculation, I don't see any problem with that in your description.
Below are the instructions on how to disable DEP:
Click on the Start menu and then go to the Control Panel.
Click on System Maintenance and then System.
Choose Advanced System Settings.
Under System Properties, select Settings from the Performance section at the top.
Click on the Data Execution Prevention tab.
Select “Turn on DEP for all programs and services except those I select”.
Find the executable file for the application that triggered the error.
Select the application causing the error and click Open to add it to your DEP Exceptions list.
Click OK to save your new settings.
Hope this helps.
Build time of XPages application containing several JARs, Java sources and ~50 XP/CC elements takes about minute to build on server via WAN. I have replicated application to local, build time dropped to ~10s.
Since few days ago build of local application is extremely slow, about 2-5 minutes. After some experiments there is workaround: to disable TCP port in location document - it drops build times to just few seconds. Even tho it works, it does not help much - testing requires user to be authenticated, so I need to replicate design changes to remote or local server - and that means to change location (online/offline) every time.
UPDATE 2013-04-04: I have duplicated my current location document and removed home and directory servers. To my surprise, with this location build times went back to few seconds - with TCP port enabled so replication is possible. Bigger surprise was the fact, that returning home/directory servers back to new location did not reproduce the problem - in fact they do not affect performance. I know it because I have renamed current location document and everything went to normal. From my understanding, "something" in client configuration was connected to location name. Thanks to Simon's tips I will investigate further.
The question is still open: I am looking for some (eclipse) preference controlling this behavior - unintended communication with server during build of local application.
Solution:
Teamstudio CIAO hooks into designer and checks for every update of design element. Seems to be lack of code optimization to me: it checks whether currently built design element (every single one, one by one) should be controlled in CIAO config database.
This explains why the problem was solved by renaming of location document. I was disappointed yesterday, when performance problems started again. Fortunately, I recalled CIAO setup to that location document about that time. CIAO uses teamstudio.ini file in DATA directory to configure what CIAO configuration database is used for every location document. Look for entry:
CIAOConfigDb[location name]=server name;CIAO\CIAOConfig.nsf
For development on local replicas with connection to server (for replication or local server), use location document with CIAO disabled.
This works only with property ForceConfigLocation=0.
Not a solution (yet!), but may help in the investigation. I'll update further if you post results later.
Debug instructions.
Add the following to the shortcut that launches the Designer client.
-RPARAMS -console -debug -separateSysLogFiles -consoleLog
Start the designer client. This will also open up the OSGi console.
Reproduce the issue. While it is still in progress in the OSGi console type the following:
dump threads
Do this three times, with a small amount of time between completion of each dump. Once done open the three heap dumps (in the IBM_TECHNICAL_SUPPORT folder) in the Heap Dump Analyser.
It will show you what threads are consistent through all three dumps. Take a look at those and look for package names/calls which may appear to be a functional area. Once you have that then you can try adding the debug for the related class.
For example: Let's say you notice "com.ibm.designer.domino.ui.commons." in the thread, then you would edit the rcpinstall.properties file. It will be in:
<Notes Install>\Data\workspace\.config\rcpinstall.properties
and you would add (start with FINE, then FINEST if nothing):
com.ibm.designer.domino.ui.commons.level=FINE
Now when you restart the designer client it will generate debug output in the workspace\logs folder for that package. You need to then go through the trace logs looking for the time when the delay occurred and see if it makes any references to related design elements.
Other open applications may get built at the same time (which looks like a bug top me). Be sure to close all other applications and the server based replica. Open applications have their icon showing in the application list and they stay open even if you close and reopen the Designer. In Designer 9 right click application and select "Close Application". In 8.5 you need to use Package Exprorer for closing.
Another good way is to use Working Sets. Only applications in open Working Set will be built (AFAIK). Have a Working Set with this one app only (and the app only in this Working Set).
update 1
If these don't help I would delete/rename bookmark.nsf, Cache.NDK and desktop8.ndk. Then open just this one app and see what happens.
update 2
Check that there are no referenced projects. Right click the application and select "Project Properties". From there "Project Referencies" and make sure no check boxes are checked.
update 3
Based on your update I would check the item names starting with $ in location document. Sometimes there are saved IP addresses etc. which could cause this problem. All those items can be removed.
If possible (and if You are not using it yet) try to use version 9 of the Domino designer (You do not have to use Domino 9 to do that - it works fine with Domino 8.5.3).
For our projects build times went down to only few seconds from few minutes. I guess that they finally noticed at IBM that the build process used to heavily relay on connection to server and done something with it.
With new designer You don't event have to replicate to local. You can directly work on Your local server.
I have been tasked with writing entries to the Windows security log. The entire project is Win32 C++ code. I have already written (with help from various online resources) a logging class that handles registration, deregistration, and code for executing the ReportEvent() call. Also, I've done the mc.exe and rc.exe steps for my event logging, if that helps establish where I'm at in the project.
My question is a multi-parter:
I've noticed at Filling Windows XP Security Event Log that there are some who believe this is not allowed by Windows. Others ( How to write log to SECURITY event Log in C#? ) imply otherwise. Possible or not?
If it is possible, how to get it to write to the security log. Is it as simple as specifying "Security" as my source name when calling RegisterEventSource()?
As far as deregistration, when should that occur? When the app is uninstalled? When the app closes? When the log entry is written?
How do I look up my log entries? I look in the Windows Event Viewer, but I don't see the entries I add with my test app, despite all the appropriate return values from the system calls. Where would I look up the events that I specified with a source name of "yarp" when I made my call to RegisterEventSource()?
For the moment, I'll just deal with the first question, because the answer to that probably renders the rest irrelevant.
Only Local Security Authority (lsass.exe) can write to the security log. This isn't a matter that something else attempting to get the privilege will fail -- it's a matter of there not being a way for anything else to even request the privilege at all (and this is by design).
From there, about the only answer to your other questions is "Sorry!"
I use AVG and it recently detected a virus. It has before ;) but this was the first time I noticed this.
When I went into the folder containing the virus, AVG immediately, automatically, detected the virus without me even clicking on the application. So I though how could it know a virus was there even when I did not even click (single click) on it.
The only possible answer is that it continuously checks the explorer folder location of all windows and scans all the files in the folder. But how does it see what folder is being viewed by me?
Please explain (if possible) with a C program that does what ever AVG did.
Also : I use Windows if that helps.
When you open a folder a bunch of file system operations is executed (you can use tools like FileMon or ProcMon to take a look at this). Your AV software monitors file access.
There are multiple ways to do this monitoring, e.g. Filter Drivers - you can find a great sample at http://www.codeproject.com/Articles/43586/File-System-Filter-Driver-Tutorial
So when you opened the folder, AV software noticed that you opened a directory, consulted its own data, and informed you about the virus.
I say 'consulted its own data', as AV tools usually don't scan files on access - they do it when the files are written to, as it doesn't make sense to scan files which were marked as clean if they haven't changed since the last scan.
Most virus scanners operate on the principle of API hooks/filters. Whenever windows needs to process a command, like opening a folder, clicking a window, executing a file, etc it generates an api call along with some information like the window coordinates clicked, or a string representing a file. Other programs can request a hook into one or more of these functions which basically says 'instead of executing this function, send it to me first, then I might send it back'. This is how many viruses work (preventing you from deleting them, or copying your keystrokes, for example), how many games/apps work (keyboard, joysticks, drag-and-drop), as well as malware detectors and firewalls.
The latter group hooks the commands, checks any incoming ones to see if they're on the level, then either allows them to resume or blocks them. In this example, opening the folder likely triggered a syscall to parse a directory, and the scanner parsed it too (eg 'realtime protection'). To view all of your hookable functions as well as what is using them, google for a free program called 'sanity check' (previously called 'rootkit hook analyzer'). Most of the red entries will be from either windows firewall or avg, so don't worry too much about what you find.