xperf -providers doesn't show the name of TraceLoggingProvider defined by TRACELOGGING_DEFINE_PROVIDER - windows

I follow the tutorial to set up a TraceLoggingProvider in my application.
During the application runs, I try to use xperf -providers to see if my user event provider is there:
I cannot see the name I defined in TRACELOGGING_DEFINE_PROVIDER but only the defined GUID is shown. Is it intended?
Instead following another tutorial with WPRP file, I just use xperf -start to capture events. And the same: I can only use GUID as parameter, not the defined name! is it also intended?
Anyway, at the end I can view the result properly in WPA and the defined name of my user event provider is visible.
are all my observaton intended?

The name you use in the C++ code is unrelated to the display name on your pc.
You'd have a displayed name (instead of GUID) if this was a manifested installed provider, but TraceLogging isn't manifested (at least, not in the classical sense - an impromptu manifest is embedded into the image, and sent in the messages).

Related

How to set application name and installation path while installing by AdminApp?

Just tried this thing for a day or two, able to do the installation using AdminApp command, but still got some problem about application name and installation path.
Reference I look from IBM said AppName is defined by display name, I think that mean it use the display name field from web.xml? But the result that I see is the application name will look like "Test_AP.war16dfd74ab1a", not exactly the same.
The installation path parameter part is also ambiguous, I don't think I see a thing looks like it.
https://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.iseries.doc/ae/rxml_taskoptions.html?view=embed#rxml_taskoptions__cmd10
import time
AdminApp.install('C:/Users/Development/Desktop/Test_AP.war', '-cell WIN-9DAB2SINode01Cell')
AdminConfig.save()
result = AdminApp.isAppReady('Test_AP')
while (result == "false"):
### Wait 5 seconds before checking again
time.sleep(5)
result = AdminApp.isAppReady('Test_AP')
print("Starting application...")
What I try to achieve is to use this script to install my service onto WAS with exact application name(same as my WAR name or display name in web.xml) and designated installation path, then start the service. But now I'm stuck at com.ibm.ws.scripting.ScriptingException: WASX7280E: An application with name "Test_AP_WAR" does not exist. Can anyone tell me how to do this?
Simple Solution
You need to include an -appname argument such as:
AdminApp.install('C:/Users/Development/Desktop/Test_AP.war', ['-cell WIN-9DAB2SINode01Cell' -appname SimpleTestConnection5_war])
Otherwise WAS will generate an application name for you.
Ideal Solution
Create an AdminApp.install command using the Admin Console. Install an enterprise application using the WAS Admin Console. On the last page, you will see a help box in the upper right corner. Click on view administrative scripting and you will be provided with an AdminApp.install command. This command can be edited with a custom location and appname.

C# - Services how to set the start parameters

I am currently working on a windows service (which starts so that is a good thing).
The big question is how can I get parameters in the start parameter field (without doing it manual ofcourse).
So what I would like to see is the following. Upon installation of the service I would like it if the following happens.
The services gets installed and the start parameters are set.
How would one do such a thing (already been browsing StackOverflow but it doesn't comply with what I want)
The reason I ask the question is the following: The service is part of a communication layer between GUI and a receiving backend. If the backend location differs (e.g. another IP address) the service needs to have the new address accordingly.
If you would like to have some more info please ask (don't down the post if something is not in order 'just ask :)')
Thanks in advance
After the update of your question, I understand what you are trying to accomplish. As far as I currently know, it is not possible to set these start parameters without using the registry. You'll have to do it manually from the services console or by using an installer. When you look at the MSDN page covering ServiceBase.OnStart (MSDN ServiceBase.OnStart method) it clearly states:
Process initialization arguments for the service in the OnStart method, not in the Main method. The arguments in the args parameter array can be set manually in the properties window for the service in the Services console. The arguments entered in the console are not saved; they are passed to the service on a one-time basis when the service is started from the control panel. Arguments that must be present when the service is automatically started can be placed in the ImagePath string value for the service's registry key (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\). You can obtain the arguments from the registry using the GetCommandLineArgs method, for example: string[] imagePathArgs = Environment.GetCommandLineArgs();
Thing is that you will still have to keep track of these registry settings when removing the service.
Therefore the link provided here ("Am I running as a service") might help out as well.
use sc.exe:
c:\>sc config <myservice> binPath= "\path\to\myservice.exe -param -param"
In your OnStart() or your service thread use something like:
string myArg = ConfigurationManager.AppSettings["MyArg"]
where in your App.Config you've added
<appSettings>
<!-- My keys -->
<add key="MyArg" value="xxx"/>
</appSettings>
Start a Windows Service passing arguments by using the System.ServiceProcess ServiceController Start(String[]) method like this:
ServiceController sc = new ServiceController("BDESVC");
sc.Start(new string[] { "argValue" });

URI scheme launching

I've been given a task to create a protocol similar to callto:, that - upon clicking on a link with it - would automatically launch an installed aplication.
I followed the microsoft guide on how a scheme should look like.
My scheme looks like this:
HKEY_CLASSES_ROOT
slican
URL Protocol = ""
DefaultIcon (Default) = "C:\Users\Okabe\Desktop\slican\SlicanP.exe,1"
shell
open
command (Default) = "C:\Users\Okabe\Desktop\slican\SlicanP.exe" "%1""
I thought that was all and tested it with
test link
test telephone link
There was no reaction whatsoever. Internet Explorer asked me if I want to search for a program that can open the content and Chrome responded with nothing, as if I clicked javascript:void(0).
How to get that worked?
Thank you for your help!
The registration you show works perfectly fine for me when I try it on Windows 7. The local app I registered in place of SlicanP.exe ran fine when I invoked a slican: URL from the Start | Run menu, and from within the address bar of Windows Explorer. So the registration works.
Do be aware that Internet Explorer runs in a lower integrity security context, so it may not have rights to run local programs. When I tried to click on an HTML link to a slican: URL, or type a slican: URL in the address bar, IE had trouble executing the local app (even after prompting for permission). I had to run IE as an administrator, then the local app ran just fine.
Also, you really should not be creating a HKEY_CLASSES_ROOT\slican key directly. Create a HKEY_CURRENT_USER\Software\Classes\slican (current user only) or HKEY_LOCAL_MACHINE\Software\Classes\slican (all users) instead. Refer to MSDN for more details:
HKEY_CLASSES_ROOT Key
Merged View of HKEY_CLASSES_ROOT
Update: Since it works in Windows 7, Microsoft probably changed how URL schemes are registered in Windows 8. For instance, phone/store apps use URI activation:
URI activation (XAML).
URI activation (HTML)
The documentation says there are two ways to register a custom URI scheme:
Internet Explorer uses two mechanisms for registering new pluggable protocol handlers. The first method is to register a URI scheme name and its associated application so that all attempts to navigate to a URI using that scheme launch the application (for example, registering applications to handle mailto: or news: URIs). The second method uses the Asynchronous Pluggable Protocols API, which allows you to define new protocols by mapping the URI scheme to a class.
You are doing the first. Try using the second instead.
However, I just noticed that "Asynchronous Pluggable Protocols" is listed on MSDN in the "Legacy APIs" section, and it has the following note:
Third-party protocol implementations won't load in Windows Store apps using JavaScript, or in the Internet Explorer in the new Windows UI.
So it may or may not work in Windows 8.
Update: I just found this:
Guidelines for file types and URIs
In Windows 8, the relationship between apps and the file types they support differs from previous versions of Windows.
Walkthrough: using Windows 8 Custom Protocol Activation
The file type and protocol association model has changed in Windows 8. Apps are no longer able to programmatically set themselves as the default handler for a file type or protocol. Instead, now the user always controls what the default handler is for a file type or protocol.
Your app can use existing protocols for communication, such as mailto, or create a custom protocol. The protocol activation extension enables you to define a custom protocol or register to handle an existing protocol.
Also have a look at this:
Setting mailto: protocol handler programmatically in Windows 8
And this:
Default Programs
if you go to C:\Users\\AppData\Local\Google\Chrome\User Data
You can edit the Local State file
Search for protocol_handler
The syntax here is a key value pair. I usually copy two mailto: and make sure that you set your protocols to false. This will mean that chrome will treat your new protocols as URI_Handler events
If you have troubles with configuring custom URI scheme, you can compare your own configuration with existing one. For example, "HKEY_CLASSES_ROOT/mailto" - most likely you have it already in your system.

IPropertyStore interface not called in a property handler

I am developing a property handler implementing IPropertyStore and IInitializeWithFile, testing on Win 8.1 x64. Property names were previously added to the system using a .propdesc file properly registered using prop.exe.
I used PROCMON.EXE to monitor the events when I re-indexed my files on disk. SearchPrototocolHost.exe loads the protocol handler, initializes it properly with IInitializeWithFile (the properties from the file seem to load OK from the file) then proceeds with PSCreatePropertyStoreFromObject presumably to retrieve the IPropertyStore interface and start retrieving the properties from the file.
Then nothing else happens, the methods from IPropertyStore are never called. Instead, SearchPrototocolHost.exe issues a CreateFile on the file to be indexed again with "Open Reparse Point", fails at getting a QueryRemoteProtocolInformation, closes the file then proceed with the next file to index.
Why does my property handler fail (is it a security issue, etc.?)?
It looks like one needs to add to the registry entry:
"HKLM" "SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved" {My_CLSID}
where My_CLSID is the GUID of my property handler!
I don't know if this is a specific requirement for handlers using IInitializeWithFile as an extra security precaution.
After three weeks of banging my head against walls, now I can "hear" the IPropertyStore methods (using MessageBeep...) when they are called by Explorer. Never mind that they crash Explorer, at least I know that IPropertyStore is not blocked!

Launching a GUI application from Windows service

I have read this post and I had little success with the given answer. It said to
use WTSEnumerateSessions to find the right desktop
but all I got was the station name in the WTS_SESSION_INFO struct. The names I saw (e.g. "console", "service") were nothing like the station/desktop names like "Winsta0\default". The answer proceed to state
then CreateProcessAsUser to start the application on that desktop (you pass it the handle of the desktop as part of the STARTUPINFO structure)
I don't think it's referring to a HANDLE variable for the desktop since STARTUPINFO has no members for that. What I think it's referring to is the lpDesktop member which allows you to specify the station/desktop name. Using names returned by WTSEnumerateSessions failed to launch any visible UI, whereas "Winsta0\default" did.
What did I do wrong?
Just tried WTSEnumerateSessions on Windows Seven: my user session (session 1) is named "Console".

Resources