I am trying to debug some COM components and want to track down CLSID and IIDs in calls to CoCreateInstance.
I am not sure how to display GUID in windbg. Any pointers for that.
Use the "display type" command:
dt GUID [address-of-guid]
For more information see the documentation.
If it is in a local variable (local to the stack frame you're in), use dv /V to dump all local variables.
I don't know anything about COM, but if this is just a normal variable (even if it's a global one), then you can always do:
alt+2 to bring up the watch window and enter the name of the variable there, eg
blahblah.dll!guid
You'll need the symbols for that, possibly need t be in source mode aswell. This is slightly nicer than dv/dt in that you don't have to type it in constantly. You can enter the address as well, I think. Note that if you don't put blahblah! then it can occasionally cause windbg to stall for a few seconds as it searches every module for something called guid.
Related
OK this is a weird on. I need to get the base address of a process in vb.net (not my application). To delve into the memory of the other process (to explore the values I needed before coding it into vb.net) I used cheat engine. Cheat engine gives me an address like so:
Client.exe + 00BBD310
The issue here is that the Client.exe address changes whenever I re-run the program. I have a declaration of the process in my code already so I've tried this:
bAddress = handle_s.MainModule.BaseAddress
Where handle_s is the process in question. The issue here is that the value I get in bAddress isn't the value that is represented by cheat engines "Client.exe" - I can work backward to work out what cheat engine is referring to as it tells me what the result of the above sum is, however as the value changes each time, I need a method by which to simple get the value in vb.net.
Any advice/suggestions welcome.
MainModule.BaseAddress gives you the address where the module was loaded (source)
Therefore it's the absolute dynamic virtual address of the module. If 0x0BBD310 is a relative offset, then adding 0x0BBD310 to MainModule.BaseAddress will give you the address of your variable at run time.
If it's not matching up with what you're seeing in Cheat Engine then you're either attached to the wrong process or you're confused.
First, appreciate you giving this a look. I have an ancient piece of software that writes old Linear PCMCIA cards. In my case, I want to use it in a specialized piece of gear called a Tech2. The software in question is called Memory Card Explorer. Now, I know for a fact it works in Windows XP with Native PCMCIA slots. However, I have a slot that is built on a Dual Systems adapter (basically an Expresscard to PCMCIA adapter).
The issue arises when following the instructions on installation issues, the program refuses to locate the Dual Adapter. Here's the example given in the manual:
"Use a similar address to the PCMCIA adapter. That address can be found using msinfo32.exe.
Eg: if the PCMCIA socket has a memory resource of F8000000 then use a MCE window command of F80D0000 using command line option of WF80D0."
So I get my adapter address which is F7FFF000 but have no idea where to add the "d" to the resource address then change it to a command. I've tried WF7FD0. Am I missing something simple in how these addresses are truncated for command line? Is there a calculator that does the conversion for you somewhere?
Thanks.
It looks like the pattern is to add 0x000D0000 to the address, take the five high nibbles of the address (which makes sense, since these sorts of addresses are typically page-aligned the bottom 3 nibbles will always be 0 on a system with 4KiB pages), and prepend 'W'. Try WF80CF.
When calling a 32 bit COM component method registered in sysWOW64 fails with an error message:
"type mismatch in method OleVarToLsVal, Unknown found, Unknown
expected"
Its win7 64 bit, but the Notes client is installed by default as a 32 bit application. The code looks like:
dim c as Variant
dim n as Variant
set c = createobject("MSWC.counters")
n = c.Get("xx")
When debugging the call, the object is set and testable with "isObject(c)", (although you can't inspect each method/property in detail in LotusScript debug).
The method is supposed to return a primitive long. I've tried setting n as long, clng-ing the values, cstr-ing the values, the parameter, strconv the parameter, using a variable for the parameter, all to no avail.
The exact same code run by WScript VBS host (in syswow64) runs the code as expected.
So, does anybody know:
If Notes 9 COM value marshalling is working for any components?
Is Notes 9 COM set to recognize the 'wow64' alternate 32 bit registry
Are there some COM related marshalling settings somewhere in the registry I can check (if so what/where are they)?
Is there some setting to tell Notes to use 32 bit components (like IIS 32bit compatibility option)
Is there anything I need to do or could do in the main OS to 'redirect or configure' COM
Or is Notes just broken again and nobody cares?
Any help appreciated - Thanks.
The easiest and probably most productive way to solve this would be to open a PMR with IBM. They should be able to answer this quite quickly.
Well, 7 years on (and seriously obsolete!) just an update for anybody looking for an answer... There are a couple of Notes settings needed and not all COM/Active-X componenets or data types are supported by LotusScript, so even if Notes is setup correctly, you still may not be able to acces/use any specific component or some methods in the component.
The user must be allowed to run unrestricted agents/code in the 'Sign or run unrestricted methods and operations:' in the security section of the server(s) document.
The Notes client execution control list ('ECL') must allow access to 'External programs' either by default or to the code-signer. An ECL warning box will ask the user to continue if the external access has not been granted.
If you try to execute an unsupported method or unsupported data type, then further errors will be issued either by LotusScript or COM/Active-X error reporting. The Notes developer help file for 'CreateObject' gives a bit more detail about unsupported data types:
LotusScript does not support identifying arguments for OLE methods or properties by name rather than by the order in which they appear, nor does LotusScript support using an OLE name by itself (without an explicit property) to identify a default property.
Results are unspecified for arguments to OLE methods and properties of type boolean, byte, and date that are passed by reference. LotusScript does not support these data types.
Relying on the 'default property' to access a default method is a common mistake and requires you to pay extra attention to the component details. It is easy to assume the component is not working, but in fact you're just not using it properly.
One way to test this is to try to open a common object available on all Windows machines (maybe others?) maybe 'FileSystemObject' (FSO) or VbScript 'regExp' component. If these work, you can build on that. Getting the 32/64bit registration correct for your client install is another element to test/get right.
For my issues, I suspect that I was using unsupported methods or data types and having used COM/Active-X in Notes occasionally, its all worked ok in general.
I have an MFC application that exposes a bunch of OLE objects for the application, and open documents.
I can connect to the server using the GUID of the application class (e.g.: in ruby for windows: WIN23OLE.new('{12345678-1234-1234-1234-12345678}')) but when I try to connect using the class name WIN32OLE.new('MyApp.Application'), it always fails with "Invalid Class String" error (HRESULT error code:0x800401f3). The same thing happens
There are no errors returned by the OLE initialisation in the MFC app, and once a connection is made by GUID, then it works fine.
I'm just really curious why the class string approach isn't working. Any ideas?
The class string is called a ProgID (short for programmatic ID), and it's really just a human-readable version of the ClassID. ProgIDs are stored in the registry under HKEY_CLASSES_ROOT, for example picking one at random from my registry:
HKEY_CLASSES_ROOT\Microsoft.XMLDOM
Under this key there is another key called CLSID:
HKEY_CLASSES_ROOT\Microsoft.XMLDOM\CLSID
And inside that key is a REG_SZ value which contains the ClassID:
{2933BF90-7B36-11D2-B20E-00C04F983E60}
So basically the way it works is that COM is going to try to find the CLSID in the registry under the specified ProgID. I'm guessing it's not there or it's inaccessible somehow. If you want to figure it out for sure, crack open REGEDIT.EXE and take a look to see if the expected registry settings are there. If they aren't, there's your answer about why it's not working (for some reason the registration of the COM component isn't creating the ProgID keys).
If the settings are there, I would recommend running Process Monitor (sysinternals.com) and set up some registry filters to see what is happening when the registry is scanned for that ProgID.
Here's a little more info about ProgIDs:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd542719(v=vs.85).aspx
I'm just familiarising myself to edit registry in VB. I am having a problem with changing a value in the HKEY_LOCAL_MACHINE key. When ever I change a value at runtime it always assumes that I am going in the "Wow6432Node" key, even though I don't put that in the parenthesis. Example: My.Computer.Registry.SetValue("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\SHOWALL", "CheckedValue", 1)
and it doesn't change the value in the string above, but changes it as if I have put "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\SHOWALL" in the string.
The program is running as administrator.
That's called registry redirection. In 64 bit Windows some registry keys (including HKLM\Software) are redirected for 32 bit applications. If you changed the build properties on your VB.NET project to x64 you would see it write to HKLM\Software. You can access the non-redirected keys using flags, but I believe those are only available for the unmanaged APIs.
But the short answer is you not doing anything wrong, and that how it is supposed to work.