COM Stuff for out of process and/or 64 bit python.

[dougransom]

1. trying to find the old oleview.exe.
2. trying to configure natlink to out of process, without recompiling.

[dougransom]

Tried installing windows sdk with visual studio. That did not work to install oleveiw.exe.
Trying windows sdk from

[dougransom]

From bing copilot:
opilot
Sent by Copilot:
Sure! Here are the relevant registry entries to ensure that your 32-bit COM component is hosted out-of-process by dllhost.exe for both 32-bit and 64-bit callers:

32-bit Registry (Wow6432Node)
HKEY_CLASSES_ROOT\Wow6432Node\CLSID{dd990001-bb89-11d2-b031-0060088dc929}
(Default) = "Natlink COM Class"
AppID = "{9814753D-A78E-4AF9-AB47-7F27B00BC598}"
InprocServer32 = "C:\Program Files (x86)\Natlink\site-packages\natlink\_natlink_core.pyd"

HKEY_CLASSES_ROOT\Wow6432Node\AppID{9814753D-A78E-4AF9-AB47-7F27B00BC598}
(Default) = "Natlink Application"
DllSurrogate = ""

64-bit Registry
HKEY_CLASSES_ROOT\CLSID{dd990001-bb89-11d2-b031-0060088dc929}
(Default) = "Natlink COM Class"
AppID = "{9814753D-A78E-4AF9-AB47-7F27B00BC598}"

HKEY_CLASSES_ROOT\AppID{9814753D-A78E-4AF9-AB47-7F27B00BC598}
(Default) = "Natlink Application"
DllSurrogate = ""

Explanation
CLSID Entries: These entries associate the CLSID with the AppID and specify the path to the 32-bit DLL in the InprocServer32 key under Wow6432Node.
AppID Entries: These entries specify the DllSurrogate value, which tells the system to use dllhost.exe to host the COM component out-of-process.
By setting up these registry entries, you ensure that any calls to the COM component, whether from a 32-bit or 64-bit application, will be handled by dllhost.exe, running the component out-of-process.

If you have any more questions or need further assistance, feel free to ask!

[dougransom]

Ok , did that still getting REGDB_E_CLASSNOTREG Class not registered when calling like this: HRESULT hr1 = CoCreateInstance(natlink_clsid, 0, CLSCTX_LOCAL_SERVER, IID_IUnknown, (void**)&pUnk); for both 32 and 64 bit clients.
Copilot
Sent by Copilot:
The REGDB_E_CLASSNOTREG error indicates that the class is not registered correctly or the registration is not being recognized. Here are some additional steps to troubleshoot and resolve this issue:

Verify 32-bit and 64-bit Registry Entries:
Ensure that the CLSID and AppID entries are correctly set in both the 32-bit and 64-bit registry hives.
Check for Correct CLSCTX:
Make sure you are using CLSCTX_LOCAL_SERVER in your CoCreateInstance call, which you are already doing:
HRESULT hr1 = CoCreateInstance(natlink_clsid, nullptr, CLSCTX_LOCAL_SERVER, IID_IUnknown, reinterpret_cast<void**>(&pUnk));

Ensure Proper Registration of the DLL:
Confirm that the 32-bit DLL is registered using the 32-bit version of regsvr32.exe:
C:\Windows\SysWOW64\regsvr32.exe "C:\Program Files (x86)\Natlink\site-packages\natlink_natlink_core.pyd"

Check DCOM Configuration:
Open dcomcnfg and navigate to Component Services -> Computers -> My Computer -> DCOM Config.
Find your application by its AppID and ensure that the settings are correct, particularly the security and identity settings.
Detailed COM Logging:
Enable detailed COM logging to get more insights into what might be going wrong. This can help identify if there are any issues with the registration or activation process.
Example Registry Entries:
Here are the registry entries you should have:
32-bit Registry (Wow6432Node):
HKEY_CLASSES_ROOT\Wow6432Node\CLSID{dd990001-bb89-11d2-b031-0060088dc929}
(Default) = "Natlink COM Class"
AppID = "{9814753D-A78E-4AF9-AB47-7F27B00BC598}"
InprocServer32 = "C:\Program Files (x86)\Natlink\site-packages\natlink\_natlink_core.pyd"

HKEY_CLASSES_ROOT\Wow6432Node\AppID{9814753D-A78E-4AF9-AB47-7F27B00BC598}
(Default) = "Natlink Application"
DllSurrogate = ""

64-bit Registry:
HKEY_CLASSES_ROOT\CLSID{dd990001-bb89-11d2-b031-0060088dc929}
(Default) = "Natlink COM Class"
AppID = "{9814753D-A78E-4AF9-AB47-7F27B00BC598}"

HKEY_CLASSES_ROOT\AppID{9814753D-A78E-4AF9-AB47-7F27B00BC598}
(Default) = "Natlink Application"
DllSurrogate = ""

Check for 64-bit Registry Entries:
Ensure that the CLSID and AppID entries are also present in the 64-bit registry hive, as shown above.
If you have verified all these steps and are still encountering the issue, it might be helpful to use a tool like Process Monitor to trace the registry access and see if there are any missing or incorrect entries being accessed during the CoCreateInstance call.

Let me know if you need further assistance or more detailed instructions on any of these steps!

Learn more

1

learn.microsoft.com
2

learn.microsoft.com
3

theogray.com
4

forums.codeguru.com
5

forum.inductiveautomation.com
+2 more

How do I

[dougransom]

Woudl the default permissions not be good enough?

Default permissions are often sufficient for many COM components, but there are cases where specific permissions need to be set to ensure proper operation, especially when dealing with out-of-process servers and cross-bitness (32-bit to 64-bit) scenarios.

Here are a few things to consider:

1. DCOM Configuration:

   • Open dcomcnfg and navigate to Component Services -> Computers -> My Computer -> DCOM Config.
   • Find your application by its AppID.
   • Right-click on it and select Properties.
   • Go to the Security tab and ensure that the appropriate permissions are set for Launch and Activation Permissions, Access Permissions, and Configuration Permissions. You might need to customize these settings to allow the necessary users or groups.

2. Registry Permissions:

   • Ensure that the registry keys for your COM component have the correct permissions. This includes both the CLSID and AppID entries.
   • Open the Registry Editor (regedit).
   • Navigate to the relevant keys (e.g., HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{dd990001-bb89-11d2-b031-0060088dc929} and HKEY_CLASSES_ROOT\AppID\{9814753D-A78E-4AF9-AB47-7F27B00BC598}).
   • Right-click on each key, select Permissions, and ensure that the necessary users or groups have Full Control or at least Read permissions.

3. User Account Control (UAC):

   • If UAC is enabled, ensure that the application has the necessary privileges to launch and interact with dllhost.exe.

4. Firewall and Security Software:

   • Ensure that any firewall or security software is not blocking the necessary communication between the 64-bit and 32-bit processes.

5. Event Viewer Logs:

   • Check the Event Viewer for any related errors or warnings that might provide more insight into the issue. Look under Windows Logs -> Application and Windows Logs -> System.

If you have verified the permissions and are still encountering the REGDB_E_CLASSNOTREG error, it might be helpful to use tools like Process Monitor to trace the registry and file system access during the CoCreateInstance call. This can help identify any missing or incorrect entries being accessed.

Let me know if you need further assistance or more detailed instructions on any of these steps!

[dougransom]

Copilot
Sent by Copilot:
To use Process Monitor for tracing and troubleshooting your COM registration issue, follow these steps:

Download and Install Process Monitor:
Download Process Monitor from the Microsoft Sysinternals website.
Extract the downloaded file and run Procmon.exe.
Start Capturing Events:
When you open Process Monitor, it will start capturing events immediately. You can stop the capture by clicking the magnifying glass icon or pressing Ctrl + E.
Clear the Display:
Clear the current display to start fresh by clicking the eraser icon or pressing Ctrl + X.
Set Filters:
To focus on specific events, set filters. For example, you can filter by process name or path:
Click on the filter icon or go to Filter -> Filter....
Add a filter for the process name of your application or dllhost.exe.
Example: Process Name is dllhost.exe then Include.
Reproduce the Issue:
Start capturing events again by clicking the magnifying glass icon or pressing Ctrl + E.
Reproduce the issue by running your 32-bit or 64-bit application that calls the COM component.
Stop Capturing:
Once you have reproduced the issue, stop capturing events by clicking the magnifying glass icon or pressing Ctrl + E.
Save the Capture:
Save the captured events to a file for analysis:
Go to File -> Save....
Choose the format (e.g., PML, CSV) and location to save the file.
Analyze the Capture:
Open the saved file in Process Monitor to analyze the events.
Look for any RegOpenKey, RegQueryValue, or RegSetValue operations related to your CLSID and AppID.
Check for any errors or access denied messages that might indicate permission issues or missing registry entries.
By following these steps, you can gather detailed information about what is happening during the CoCreateInstance call and identify any issues with the COM registration or permissions.

If you need further assistance with analyzing the logs or interpreting the results, feel free to ask!

[dougransom]

Interesting. So I am using the 32bit client, CoCreateInstance reads HKCR\WOW6432Node\CLSID{dd990001-bb89-11d2-b031-0060088dc929}\InprocServer32

It never queries the AppID Value thought it does query the ThreadingModel value.

HKCR\WOW6432Node\CLSID{dd990001-bb89-11d2-b031-0060088dc929}\InprocServer32\ThreadingModel

Oddly it queries this value: HKCR\WOW6432Node\CLSID{dd990001-bb89-11d2-b031-0060088dc929}\InprocServer32\InprocServer32

These are a little weird:
HKCR\WOW6432Node\CLSID{dd990001-bb89-11d2-b031-0060088dc929}\InprocServer32(Default) the result is BUFFER_OVERFLOW.

[dougransom]

Interesting. So I am using the 32bit client, CoCreateInstance reads HKCR\WOW6432Node\CLSID{dd990001-bb89-11d2-b031-0060088dc929}\InprocServer32

It never queries the AppID Value thought it does query the ThreadingModel value.

HKCR\WOW6432Node\CLSID{dd990001-bb89-11d2-b031-0060088dc929}\InprocServer32\ThreadingModel

Oddly it queries this value: HKCR\WOW6432Node\CLSID{dd990001-bb89-11d2-b031-0060088dc929}\InprocServer32\InprocServer32

These are a little weird:
HKCR\WOW6432Node\CLSID{dd990001-bb89-11d2-b031-0060088dc929}\InprocServer32(Default) the result is BUFFER_OVERFLOW.

[dougransom]

It sounds like the CoCreateInstance call is not recognizing the AppID and is instead trying to load the DLL in-process, which is not what you want. The BUFFER_OVERFLOW result is also unusual and might indicate an issue with the registry entry or how it's being read.

Here are a few things to check and try:

1. Registry Cleanup:

   • Ensure there are no duplicate or conflicting entries in the registry. Sometimes, leftover entries from previous registrations can cause issues.
   • Carefully delete any unnecessary or incorrect entries under HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{dd990001-bb89-11d2-b031-0060088dc929} and re-register the DLL.

2. Correct Registry Entries:

   • Double-check that the AppID and DllSurrogate values are correctly set. Here’s a recap of the necessary entries:

   32-bit Registry (Wow6432Node):

   HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{dd990001-bb89-11d2-b031-0060088dc929}
       (Default) = "Natlink COM Class"
       AppID = "{9814753D-A78E-4AF9-AB47-7F27B00BC598}"
       InprocServer32 = "C:\\Program Files (x86)\\Natlink\\site-packages\\natlink\\_natlink_core.pyd"
       ThreadingModel = "Apartment"
   
   HKEY_CLASSES_ROOT\Wow6432Node\AppID\{9814753D-A78E-4AF9-AB47-7F27B00BC598}
       (Default) = "Natlink Application"
       DllSurrogate = ""
   

   64-bit Registry:

   HKEY_CLASSES_ROOT\CLSID\{dd990001-bb89-11d2-b031-0060088dc929}
       (Default) = "Natlink COM Class"
       AppID = "{9814753D-A78E-4AF9-AB47-7F27B00BC598}"
   
   HKEY_CLASSES_ROOT\AppID\{9814753D-A78E-4AF9-AB47-7F27B00BC598}
       (Default) = "Natlink Application"
       DllSurrogate = ""
   

3. Check for Typographical Errors:

   • Ensure there are no typos in the registry keys and values. Even a small mistake can cause the registration to fail.

4. Re-register the DLL:

   • Unregister the DLL first using the 32-bit version of regsvr32:

     C:\Windows\SysWOW64\regsvr32.exe /u "C:\Program Files (x86)\Natlink\site-packages\natlink\_natlink_core.pyd"

   • Then, re-register it:

     C:\Windows\SysWOW64\regsvr32.exe "C:\Program Files (x86)\Natlink\site-packages\natlink\_natlink_core.pyd"

5. Check Permissions:

   • Ensure that the registry keys have the correct permissions. The user account running the application should have read access to these keys.

6. Process Monitor Analysis:

   • Use Process Monitor to trace the registry access again. Look for any ACCESS DENIED or other errors that might indicate permission issues or missing entries.

If these steps don't resolve the issue, it might be helpful to provide more details about the exact setup and any additional error messages you are seeing. This can help pinpoint the problem more accurately. Let me know if you need further assistance!

[dougransom]

Ok, CoCreateInstance flagas are part of the problem, which we don't control. https://stackoverflow.com/questions/1881216/can-i-force-my-com-object-to-use-dllsurrogate

[dougransom]

To make your 64-bit COM object callable from a 32-bit COM client, you can use the DllSurrogate mechanism. This involves adding specific registry keys and values. Here are the steps:

Locate the CLSID:
Navigate to HKEY_CLASSES_ROOT\WOW6432Node\CLSID{dd990001-bb89-11d2-b031-0060088dc929}.
Add the AppID:
If the AppID value does not exist under this key, create a new REG_SZ value named AppID and set its data to a unique identifier (it can be the same as the CLSID).
Create the AppID Key:
Navigate to HKEY_CLASSES_ROOT\WOW6432Node\AppID.
Create a new key named {dd990001-bb89-11d2-b031-0060088dc929} (the same as the CLSID).
Add the DllSurrogate Value:
Under the newly created AppID key, add a new REG_SZ value named DllSurrogate and leave its data empty.
Verify the InprocServer32 Key:
Ensure that the InprocServer32 key under HKEY_CLASSES_ROOT\WOW6432Node\CLSID{dd990001-bb89-11d2-b031-0060088dc929} points to the correct DLL path and has the appropriate ThreadingModel value.
Here is a summary of the registry structure you need to create:

HKEY_CLASSES_ROOT
└── WOW6432Node
└── CLSID
└── {dd990001-bb89-11d2-b031-0060088dc929}
└── InprocServer32
└── (Default) = "C:\Path\To\Your\DllFile.dll"
└── ThreadingModel = "Apartment"
└── AppID = "{dd990001-bb89-11d2-b031-0060088dc929}"
└── AppID
└── {dd990001-bb89-11d2-b031-0060088dc929}
└── DllSurrogate = ""

This setup allows the 32-bit COM client to call the 64-bit COM object by running it in a surrogate process12.

[dougransom]

HKEY_CLASSES_ROOT\WOW6432Node\CLSID{dd100006-6205-11cf-ae61-0000e8a28647}\LocalServer32

What registry additions are required so this can be called from a 64 bit com app?
Sent by Copilot:
To make a 32-bit COM server callable from a 64-bit COM client, you need to ensure that the necessary registry entries are present under both the 32-bit and 64-bit registry views. Here are the steps to add the required registry entries:

Add the CLSID under the 64-bit registry view:
Navigate to HKEY_CLASSES_ROOT\CLSID{dd100006-6205-11cf-ae61-0000e8a28647}.
Ensure that the LocalServer32 key is present and points to the correct path of the 32-bit server executable.
Add the AppID:
If the AppID value does not exist under this key, create a new REG_SZ value named AppID and set its data to a unique identifier (it can be the same as the CLSID).
Create the AppID Key:
Navigate to HKEY_CLASSES_ROOT\AppID.
Create a new key named {dd100006-6205-11cf-ae61-0000e8a28647} (the same as the CLSID).
Add the DllSurrogate Value:
Under the newly created AppID key, add a new REG_SZ value named DllSurrogate and leave its data empty.
Here is a summary of the registry structure you need to create:

HKEY_CLASSES_ROOT
└── CLSID
└── {dd100006-6205-11cf-ae61-0000e8a28647}
└── LocalServer32
└── (Default) = "C:\Path\To\Your\32BitServer.exe"
└── AppID = "{dd100006-6205-11cf-ae61-0000e8a28647}"
└── AppID
└── {dd100006-6205-11cf-ae61-0000e8a28647}
└── DllSurrogate = ""

Explanation:
CLSID Section:
Added the AppID value under the CLSID key to link the COM class to the AppID.
AppID Section:
Created a new AppID key with the same GUID.
Added the DllSurrogate value under the AppID key. The value is set to an empty string, which is necessary for the surrogate process.
This setup allows the 64-bit COM client to call the 32-bit COM server by running it in a surrogate process12.

If you need further assistance or run into any issues, feel free to ask!

1
learn.microsoft.com
2
learn.microsoft.com
3
answers.microsoft.com
Sent by you:
Can you write a .reg file that will do that?
Sent by Copilot:
Sure! Here is a .reg file that will add the necessary registry entries to make your 32-bit COM server callable from a 64-bit COM client:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID{dd100006-6205-11cf-ae61-0000e8a28647}]
@="Your COM Server Description"
"AppID"="{dd100006-6205-11cf-ae61-0000e8a28647}"

[HKEY_CLASSES_ROOT\CLSID{dd100006-6205-11cf-ae61-0000e8a28647}\LocalServer32]
@="C:\Path\To\Your\32BitServer.exe"

[HKEY_CLASSES_ROOT\AppID{dd100006-6205-11cf-ae61-0000e8a28647}]
@="Your COM Server Description"
"DllSurrogate"=""

[HKEY_CLASSES_ROOT\WOW6432Node\CLSID{dd100006-6205-11cf-ae61-0000e8a28647}]
@="Your COM Server Description"
"AppID"="{dd100006-6205-11cf-ae61-0000e8a28647}"

[HKEY_CLASSES_ROOT\WOW6432Node\CLSID{dd100006-6205-11cf-ae61-0000e8a28647}\LocalServer32]
@="C:\Path\To\Your\32BitServer.exe"

[HKEY_CLASSES_ROOT\WOW6432Node\AppID{dd100006-6205-11cf-ae61-0000e8a28647}]
@="Your COM Server Description"
"DllSurrogate"=""

Explanation:
CLSID Section:
Added the AppID value under the CLSID key to link the COM class to the AppID.
Specified the path to the 32-bit server executable under LocalServer32.
AppID Section:
Created a new AppID key with the same GUID.
Added the DllSurrogate value under the AppID key. The value is set to an empty string, which is necessary for the surrogate process.
WOW6432Node Section:
Mirrored the CLSID and AppID entries under WOW6432Node to ensure the 32-bit server is registered correctly for 64-bit clients.
Replace "C:\Path\To\Your\32BitServer.exe" with the actual path to your 32-bit server executable.

Save this content to a file with a .reg extension and then double-click the file to add the entries to the registry.

If you need further assistance or run into any issues, feel free to ask!

[dougransom]

Be aware CoPilot isn't that great a programmer.

I have found that you only want your classid and appid in the registry section (32 bit Syswow or 64 bit) based on the architecture it is compiled for. If the appid correctly has the DLLSurrogate value of an empty string, then the cross 32/64 bit com calls should be marshalled by COM.

[dougransom]

Copilot
Sent by Copilot:
Yes, the 64-bit server can call a method on the interface IX received from the 32-bit server, but there are some important considerations to keep in mind:

Marshalling: Since you are dealing with cross-process communication between 32-bit and 64-bit processes, COM will need to marshal the interface pointers correctly. Ensure that the interface IX is properly marshaled between the two processes.
Proxy/Stub DLLs: You may need to have the appropriate proxy/stub DLLs registered on both the 32-bit and 64-bit sides to handle the marshalling of the interface IX.
Threading Model: Be mindful of the threading model used by both the 32-bit and 64-bit servers. COM will handle the marshalling based on the threading model, so make sure they are compatible.
Compatibility: Ensure that the interface IX is designed to be compatible with both 32-bit and 64-bit environments. This includes making sure that any data structures or parameters passed through the interface are correctly aligned and sized for both architectures.
If these considerations are properly addressed, the 64-bit server should be able to call methods on the interface IX received from the 32-bit server without any issues.

If you have any specific concerns or need further assistance, feel free to ask!

[dougransom]

I need to extract a type lib from a 3d party dll. What I really need to do is marshall some of the interfaces from DragonNaturally Speaking (a Nuance/Microsoft Product) into a 64 bit com object.

[dougransom]

To extract a type library from a third-party DLL and marshal interfaces from Dragon NaturallySpeaking into a 64-bit COM object, you can follow these steps:

Extracting the Type Library

1. Using OLE/COM Object Viewer:

   • Open the OLE/COM Object Viewer tool, which is included with Visual Studio.
   • Go to File > View TypeLib and select the DLL file.
   • Save the type library as a .tlb file.

2. Using tlbexp Tool:

   • If the DLL is a .NET assembly, you can use the tlbexp (Type Library Exporter) tool to generate a type library.
   • Open a Command Prompt and run the following command:

     tlbexp yourassembly.dll /out:yourlibrary.tlb

   • Replace yourassembly.dll with the name of your DLL and yourlibrary.tlb with the desired name for the type library.

Marshalling Interfaces

To marshal interfaces from a 32-bit COM server (Dragon NaturallySpeaking) to a 64-bit COM object, you need to ensure proper marshalling and compatibility:

1. Register Proxy/Stub DLLs:

   • Ensure that the appropriate proxy/stub DLLs are registered on both the 32-bit and 64-bit systems to handle the marshalling of the interfaces.

2. Use CoCreateInstance:

   • Use CoCreateInstance to create instances of the COM objects and obtain the interfaces.

3. Marshalling with CoMarshalInterface and CoUnmarshalInterface:

   • Use CoMarshalInterface to marshal the interface from the 32-bit server.
   • Use CoUnmarshalInterface to unmarshal the interface in the 64-bit server.

Here is a basic example in C++:

// 32-bit server side
IUnknown* pUnknown = nullptr;
HRESULT hr = CoCreateInstance(CLSID_DragonNaturallySpeaking, nullptr, CLSCTX_INPROC_SERVER, IID_IUnknown, (void**)&pUnknown);
if (SUCCEEDED(hr)) {
    IStream* pStream = nullptr;
    hr = CreateStreamOnHGlobal(nullptr, TRUE, &pStream);
    if (SUCCEEDED(hr)) {
        hr = CoMarshalInterface(pStream, IID_IUnknown, pUnknown, MSHCTX_LOCAL, nullptr, MSHLFLAGS_NORMAL);
        // Send the stream to the 64-bit server
    }
}

// 64-bit server side
IStream* pStream = nullptr; // Receive the stream from the 32-bit server
IUnknown* pUnknown = nullptr;
HRESULT hr = CoUnmarshalInterface(pStream, IID_IUnknown, (void**)&pUnknown);
if (SUCCEEDED(hr)) {
    // Use the interface
}

Additional Considerations

• Threading Model: Ensure that the threading models of both servers are compatible.
• Compatibility: Verify that the interfaces and data structures are compatible between 32-bit and 64-bit environments.

By following these steps, you should be able to extract the type library from the third-party DLL and marshal the interfaces from Dragon NaturallySpeaking into your 64-bit COM object.

If you have any specific questions or need further assistance, feel free to ask!

Source: Conversation with Copilot, 2024-10-03
(1) Tlbexp.exe (Type Library Exporter) - .NET Framework. https://learn.microsoft.com/en-us/dotnet/framework/tools/tlbexp-exe-type-library-exporter.
(2) Type Library Viewers and Conversion Tools - Win32 apps. https://learn.microsoft.com/en-us/windows/win32/com/type-library-viewers-and-conversion-tools.
(3) how-to-generate-interop-assemblies-from-type-libraries.md. https://github.com/dotnet/docs/blob/main/docs/framework/interop/how-to-generate-interop-assemblies-from-type-libraries.md.
(4) How to: Generate Interop Assemblies from Type Libraries. https://learn.microsoft.com/en-us/dotnet/framework/interop/how-to-generate-interop-assemblies-from-type-libraries.
(5) Dragon NaturallySpeaking 12 Feature Matrix - nuance.custhelp.com. https://nuance.custhelp.com/app/answers/detail/a_id/6918/~/dragon-naturallyspeaking-12-feature-matrix.
(6) [SOLVED] Dragon NaturallySpeaking 15.6 Stopped Working After Windows .... https://answers.microsoft.com/en-us/windows/forum/all/solved-dragon-naturallyspeaking-156-stopped/73ac9ebb-781b-40b0-9156-4761bafa0e26.
(7) Dragon NaturallySpeaking Feature Matrix - Nuance Communications. https://www.nuance.com/content/dam/nuance/en_us/collateral/dragon/feature-matrix/fm-dragon-naturally-speaking-en-us.pdf.
(8) undefined. https://nuance.custhelp.com/app/answers/detail/a_id/29800/kw/win11/session/L3RpbWUvMTY2MTkzNjc0Ni9zaWQvZlVnS2NzODVqZFBWUzclN0VUUEY1Q1ExU3NoMjAwWEFiN1psU2F2UE11VGNXVTdaVk5GZXd3NSU3RUFma2tfbWRRVlNIbWZCbThTSW8xTUIxRGI1MFlDX29GaFhnRjQxSWMwZzU5NFd1MGJ1c1U2cmZibDA5MnQzVTBoZyUyMSUyMQ%3D%3D.
(9) undefined. http://supportcontent.nuance.com/dragon/15/DPG_DPI_15_Cleaner.exe.
(10) en.wikipedia.org. https://en.wikipedia.org/wiki/Dragon_NaturallySpeaking.

[dougransom]

Where exactly can i find ole/com object viewer? I have not seen it invisual studio 2022 edition.

[dougransom]

The OLE/COM Object Viewer (oleview.exe) is not included directly within Visual Studio 2022, but it is part of the Windows SDK. You can find it in the following directory after installing the Windows SDK:

C:\Program Files (x86)\Windows Kits\10\bin\[version]\[architecture]\oleview.exe

Here's how you can access it:

1. Install the Windows SDK: If you haven't already, download and install the Windows SDK from the Microsoft website.
2. Navigate to the Directory: Open File Explorer and navigate to the directory mentioned above. Replace [version] with the version number of the SDK and [architecture] with x86 or x64 depending on your system.
3. Run OLE/COM Object Viewer: Double-click oleview.exe to open the OLE/COM Object Viewer.

Once you have it open, you can use it to view type libraries and interfaces by selecting File > View TypeLib and choosing the DLL file you want to inspect¹.

If you need further assistance or have any other questions, feel free to ask!

¹: OLE/COM Object Viewer - Microsoft Learn

Source: Conversation with Copilot, 2024-10-03
(1) OLE/COM Object Viewer - Win32 apps | Microsoft Learn. https://learn.microsoft.com/en-us/windows/win32/com/ole-com-object-viewer.
(2) Type Library Viewers and Conversion Tools - Win32 apps. https://learn.microsoft.com/en-us/windows/win32/com/type-library-viewers-and-conversion-tools.
(3) win32/desktop-src/com/ole-com-object-viewer.md at docs - GitHub. https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/com/ole-com-object-viewer.md.
(4) GitHub - tyranid/oleviewdotnet: A .net OLE/COM viewer and inspector to .... https://github.com/tyranid/oleviewdotnet.
(5) Viewing Managed COM Objects Through Native Pointers. https://devblogs.microsoft.com/visualstudio/viewing-managed-com-objects-through-native-pointers/.

[dougransom]

I finally found the ole com object viewer on my pc!

[dougransom]

To use the OLE/COM Object viewer you need to install the windows sdk and locate it as described above.

YOu need to register the DLL it gives an error about, or try running oleview as admin.

[dougransom]

With oleview, was able to find this (picking one of the interfaces in dpeech.h.

This gives promise we may be able to marshall the interfaces used by natlink between processes (as always happens between 32 and 64 bit com objects).

[dougransom]

With some more debug statements, in BOOL CDragonCode::natConnect( IServiceProvider * pIDgnSite, BOOL bUseThreads ) the following is failing:

		__uuidof(DgnDictate), __uuidof(ISRCentral), (void**)&m_pISRCentral );
	RETURNIFERROR( rc, "IServiceProvider::QueryService(DgnDictate)" );

[11392] An error occurred calling IServiceProvider::QueryService(DgnDictate) from DragonCode.cpp 1713.  The error code was 0x80040154 (-2147221164).

Likely either DgnDictate or iSRCentral isn't recognized in 64 bit or can't marshall between 64 and 32 bit architectures.
0x80040154 is class not registered.
DgnDictate is hosted in natspeak.exe.

I think ISRCentral is from microsoft speach api. There are a couple type libs that can be inspected with OLEVIew.

[dougransom]

This could be part of the puzzle, so 64 bit objects can call into dragon perhaps:

KEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{dd10ffff-6205-11cf-ae61-0000e8a28647} and HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\natspeak.exe exist. Several COM have a LocalServer32 subkey with a value 'C:\Program Files (x86)\Nuance\NaturallySpeaking16\Program\natspeak.exe'. Can I modify the registry, so a 64 bit COM object can access those com objects?
Yes, you can modify the registry to allow a 64-bit COM object to access those COM objects. Here's how you can do it:

Create a New Key for 32-bit COM Objects: Add a new key under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\AppID. The new key should be named with the same GUID as the COM object1.

Set the DllSurrogate Value: Under the new key you just created, add a new REG_SZ (string) value named DllSurrogate and leave the value empty.

Ensure Proper Registration: Make sure that the COM objects are properly registered in both the 32-bit and 64-bit registry locations.

Here's a step-by-step example:

plaintext
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\AppID\{dd10ffff-6205-11cf-ae61-0000e8a28647}
    (New Key) DllSurrogate (String Value) = (Leave empty)
By doing this, you're essentially telling the system to use the 32-bit COM objects from a 64-bit application.

Would you like more detailed instructions or assistance with any specific part of this process?

[dougransom]

There is a .reg file which creates some of the above registry entries in natlink. I am not sure how to resolve those errors above related to IServiceProvider::QueryService.

Trying the above with 32 bit might work in an out of process COM server.