Question
when you right-click on the desktop (or folder, file, etc) the context menu entries that appear are either statically generated or dynamically generated via a loaded DLL that implements specific interfaces. read more about the differences between static entries and dynamic ones here.
I just bought a new computer and decided to fully customize my windows context menu.
Basically, this question asks about complete control over your windows context menus, even the dynamic ones, and even the built-in ones(if possible).
The static entries are easy to manage and can be easily managed via the registry or a tool.
the dynamically generated entries are the problem because it's hard to understand which of the loaded DLLs caused a certain entry label to apear.
For example: context menu on certain file types(like .txt) will load an entry "Move to OneDrive". how do I find the DLL that loaded that sentence?
so to summer up, how do i:
get from the context menu entry label(eg 'Move to OneDrive') the path of the ContextMenuHandlers DLL that loaded it. Alternatively, finding out the ContextMenuHandler that generated this entry.
✅ disable its loading. (can be done by editing the UID to something else,for example prefixing with '-')
some values are restored after reboot, how do I cancel that?
('Move to OneDrive' is a true and annoying example but I asking about any entry, even the 'Rename' or 'Properties')
Possible directions:
Using Sysinternals process explorer we can search a handle or a loaded DLL, however, how can you tell in a DLL generated a specific string(eg 'Move to OneDrive')?
Example:
for documentation purposes, not actual part of the question
Following this example we can understand,
The registry entries that are responsible for the dynamic entries on the directory context menu are listed in Computer\HKEY_CLASSES_ROOT\Directory\shellex\ContextMenuHandlers
let's take the EPP Key for example:
we can see that the value of the EPP key is {09A47860-11B0-4DA5-AFA5-26D86198A780}
following this example:
HKEY_CLASSES_ROOT
.myp
(Default) = MyProgram.1
CLSID
{00000000-1111-2222-3333-444444444444}
InProcServer32
(Default) = C:\MyDir\MyCommand.dll
ThreadingModel = Apartment
{11111111-2222-3333-4444-555555555555}
InProcServer32
(Default) = C:\MyDir\MyPropSheet.dll
ThreadingModel = Apartment
MyProgram.1
(Default) = MyProgram Application
Shellex
ContextMenuHandler
MyCommand
(Default) = {00000000-1111-2222-3333-444444444444}
PropertySheetHandlers
MyPropSheet
(Default) = {11111111-2222-3333-4444-555555555555}
using our value for the EPP entry {09A47860-11B0-4DA5-AFA5-26D86198A780}, we can understand that the DLL that loaded this entry is listed here Computer\HKEY_CLASSES_ROOT\CLSID\{09A47860-11B0-4DA5-AFA5-26D86198A780}\InprocServer32, and in this case the value of this entry is C:\Program Files\Windows Defender\shellext.dll
We can 'Windows Defender' in the path, so we can assume it's responsible for loading the context entry with the label 'Scan with windows defender'
However, seems that that story does not end here, after disabling all static and dynamic entries for context directory there are still entries in the context menu. how do I revel which DLL loaded them?
Related
Windows 8 has a feature: it can launch an application from the search panel (on the right side of the screen). It works like following:
Developer registers his or her application following this instruction. It is a bit legacy instruction, but the project I participate in uses this way to register its settings.
At user logon Windows creates (if none exists) a special .xml file in C:\User\<UserName>\AppData\Packages\windows.immersivecontrolpanel_cw5n1h2txyewy\LocalState\Indexed\Settings\en-US with content shown below. This file has extension settingscontent-ms
As soon as user clicked on this file, the system launches the specified application (actually explorer calls for it, as I discovered by ProcMon).
Xml file content:
<?xml version="1.0" encoding="UTF-8"?>
<PCSettings>
<SearchableContent xmlns="http://schemas.microsoft.com/Search/2013/SettingContent">
<ApplicationInformation>
<AppID>windows.immersivecontrolpanel_cw5n1h2txyewy!microsoft.windows.immersivecontrolpanel</AppID>
<DeepLink>%Canonical name or application path%</DeepLink>
<Icon>%App path%,-%Resource number%</Icon>
</ApplicationInformation>
<SettingIdentity>
<PageID>%GUID as in instruction above%</PageID>
<HostID>{7E0522FC-1AC4-41CA-AFD0-3610417A9C41}</HostID>
<Condition>shcond://v1#RegkeyExists;0;Regkey;HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel\NameSpace\%GUID as in instruction above%</Condition>
</SettingIdentity>
<SettingInformation>
<Name>#%App path%,-%Resource number%</Name>
<Description>#%App path%,-%Resource number%</Description>
<HighKeywords>%App decription%</HighKeywords>
</SettingInformation>
</SearchableContent>
</PCSettings>
We can see node with the name HostID. Windows writes specified in code GUID to this node, but it breaks the ability of my application to work. If I try to execute my app through this "shortcut" by clicking on xml file or chosing my app in search panel, the system shows me a message: "Unspecified error".
When I manually change the HostID value to {12B1697E-D3A0-4DBC-B568-CCF64A3F934D}, it starts to wrk fine.
I looked through registry in order to find something about these two GUIDs, but I didn't find anything. Also I looked for the difference between registry values corresponding to my app and to another, but working, app and didn't find any significand differences too.
Also I tried to delete this file and login into the system under ProcMon, I caught some moments: explorer tries to open the file and fails with ERROR_FILE_NOT_FOUND, explorer creates missing file, reads registry and writes something to created file, then it closes the file. But I didn't find anything interesting in between of these messages, that can help me to solve my problem.
I found out that registry key HKEY_CLASSES_ROOT\CLSID\%App GUID%\System.ApplicationName contains exactly the same with DeepLink tag (it was the first error in my app - specified key was empty), but the proble with "wrong" HostID remains.
Does anyone know, what it is and how to make Windows to write the rigth GUID to this tag, or at least some useful info about this tag? I just can't imagine anything else to change, but I think, that I need to change something in corresponding to my app registry keys.
I found the solution: just put app's GUID (the same as in PageID) into DeepLink.
To do this, you need to write this GUID as string value to HKEY_CLASSES_ROOT\CLSID\%App GUID%\System.ApplicationName.
That's the solution. However, I haven't found the meaning of HostID tag :(
Is there an easy way of generating the memory dump for the crashed application?
I have a situation in which the customer received the code which is generating the crash, as the code itself has no signal handlers for the backtrace generation on abort I was wondering if there is an easy way of telling windows to generate the memory dump of the crashing application.
Ideal solution wouldn't involve the installation of the debug tools (or the code modification) but if this is not possible, it would be really helpful to know.
One simple way to dump memory when application crashes is by using windows taskmanager.
When ever an exception or an application error occurs windows pops up an memory dialog and shows the address location which was causing a crash.Before you click ok on the message box open Task Manger and right click on the crashed application and select Create Dump file.Take a look at the screen shot below.
Select the file
2)Another way of generating user mode dumps is by adding the following registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting >\LocalDumps\application.exe
application.exe should be replaced by the application name which is under scanner.
under this key following values can be added
DumpFolder
The path where the dump files are to be stored. If you do not use the default path, then make sure that the folder contains ACLs that allow the crashing process to write data to the folder.
For service crashes, the dump is written to service specific profile folders depending on the service account used. For example, the profile folder for System services is %WINDIR%\System32\Config\SystemProfile. For Network and Local Services, the folder is %WINDIR%\ServiceProfiles.
DumpCount
The maximum number of dump files in the folder. When the maximum value is exceeded, the oldest dump file in the folder will be replaced with the new dump file.
DumpType
Specify one of the following dump types:
0: Custom dump
1: Mini dump
2: Full dump
CustomDumpFlags
The custom dump options to be used. This value is used only when DumpType is set to 0.
The options are a bitwise combination of the MINIDUMP_TYPE enumeration values.
I have found the answer myself, the msdn specifies the debug registery in the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error\LocalDumps
The following values need to be set:
DumpFolder
DumpCount
DumpType
CustomDumpFlags
The extensive documentation is available here.
If the registers do not exist it is possible to create them manually and windows will pick it up.
Also this is possible without directly modifying the registry with following steps:
Click Start, and then click Control Panel.
Double-click System, and then click Advanced system settings.
Click the Advanced tab, and then click Settings under Startup and Recovery.
In the Write debugging information list, click Small memory dump (64k).
I am migrating vb4 application to vb6.0 app. I am using windows xp. I want to add ocx controls to the application. Any simple steps to do add ocx controls/files to the application. What are .frm files
Object = "{bla-lablabla-lablabla}#2.0#0"; "THREED20.OCX"
Object = "{blabla-bla-bla-blabla-blablabla}#2.0#0"; "vsview2.ocx"
I want to add these two ocx controls in vb6 ( 16 bit to 32 bit)
You don't state if you already have the OCX files.
To address your first question on how to add OCX controls to your VB6 project. You need to go to Projects -->Components( CtrlT ) then click the Browse button and navigate to where the OCX is located and select it.
As far as the actual OCX Files are concerned there is a Threed20.ocx that is included on the VB6 install media, I believe it is on Disk 2. There is also a registry file that you will need to run to enable design time use of the control. As far as the vsview2.ocx file is concerned if it is not a 32 bit OCX you will need to contact the vendor, who I believe is ComponentSource to get the proper version if you don't currently have it.
And as far is what is a .frm file it is according to this article
A form holds the description of all objects and their properties for each form, as well as the basic code that you have written to respond to the events.
Here is my scenario. I am using Quicktest Pro (VB) to create an ActiveX object from a Labview VI that I built into an executable. In the build specs of the VI I have enabled ActiveX server option (ActiveX server name: "MyLabviewProgram") and in the VI Tools>Options>VI Server: Configuration the ActiveX box is checked.
So in QTP my code is:
Set IvApp = CreateObject("MyLabviewProgram.Application")
Set Vi = IvApp.getVIReference("MyLabviewVI.vi")
Vi.Call ParamNames, ParamVals
Upon running this I get a Run Error on the first line:
ActiveX component can't create object: 'MyLabviewProgram.Application'
I am having trouble figuring out why it errors. From National Instruments website they have a step in on one of their community pages about "LabVIEW Executable Used as ActiveX Server". The step is after building the EXE, 5. Run the EXE at least once on the target to activate the .TLB file. I've run the executable but not sure what they mean by on the target.
Does anyone have a suggestion on what I need to do to get this working?
Your description sounds like you correctly created a vi .exe. "On the Target" probably means "On the Target PC". The EXE adds all COM registration entries to the Windows registry each time it is executed.
It sounds like you haven't verified the COM registration entries are present in the registry yet. That's the first debugging step.
Run regedit.exe and search for MyLabviewProgram.Application under the HKEY_CLASSES_ROOT sub-key. You should find an entry that contains a sub-key that contains a value that contains a GUID (a large hexadecimal number).
That "class ID" GUID should be referenced under the HKCR/CLSID key. That reference should contain a LocalServer32 sub-key with the default value pointing to your application's .EXE filepath with the /Automation argument appended.
It seems likely that one of these steps will fail. I can't say exactly which one without more information.
In other words, can I count on a control ID as a reliable identifier?
From some reading I've done, it sounds like .NET controls can have control IDs that change with every run, is this so for Win32 apps as well, or are they something that's hardcoded in the source?
The window/control in question is actually an Internet Explorer dialog if that helps.
In general win32 dialog resource IDs do not change when you run the app. However, they are internal implementation details and as such they are subject to change whenever an update (patch, service pack, major release) to the application is made.
In general all of IE's dialogs use hard-coded control IDs. There may be some that are dynamic. If you give the specific control I might be able to give you a better answer.
The answer is "it depends on the circumstances, but in the majority of programs, these will not change across multiple executions." In general, a control ID or resource ID will be the same across every execution of the same program.
In most implementations, resources are stored in the resource section of the PE executable and are assigned a resource ID within that data structure. Usually, the developer specifies the resource in a .rc file.
The exceptional case is via APIs such as CreateDialogIndirect() which allow IDs specified through the API at runtime. Such dynamic creation is uncommon, however. Consistency of resource IDs and control IDs is the expected condition, so even in the case of the CreateXXXIndirect() API, users of the API would be ill-advised to chose a varying ID.
Microsoft has spent years trying to deal with applications which embed assumptions about internal windows implementation details. One of the biggest causes of compatibility problems for IE8 was caused by applications which made assumptions about the window order of IE controls. When the UI was changed in IE8, the controls moved and a number of browser plugins broke hideously.
In general you should never ever make assumptions about controls in an application that you didn't write - your code WILL break in the future (not might break, will break).
As a general rule, no they don't change between runs. Control IDs are usually specified with a dialog template, and that's a static resource compiled into an .exe or .dll. Controls can also be created using a regular call to CreateWindow or CreateWindowEx. In such cases, the ID is usually a constant, but it could be anything in principal (even a random value).
In any case, if you're planning to muck around with a dialog in another application, then you are asking for trouble. Control IDs can and do change between different versions of a program.
It depends on the control. Controls that are dynamically created could have a different ID every time they are created. Controls based on static dialog resources will have static IDs.
Even if a dialog is backed by a dialog resource template, controls can be added dynamically at runtime and those controls could have dynamically generated IDs.
Depending on your intent, it may be acceptable to store and reuse it for future lookups or traces; but in general it isn't safe.
If the window is based upon a dialog template, items declared in the template generally don't change. It is perfectly safe under typical circumstances to use these as identifiers.
Sometimes the window class name or a portion of it can be used as an identifier instead, depending on the window host.
If the dialog is one of the standard prompts from internet explorer, you may want to use text stored in adjacent controls or the dialog caption as additional verification info (if localized versions of IE are not an issue). If the dialog is a window that embeds an instance of MSHTML/IE; none of these options may be viable- but you can use OLE accessibility to get at the document shown and then browse the DOM from there.