vb.net 2010 - reading from registry doesn't work - win 7 - vb.net

I thought this would be dead simple however....
Right, so all I'm simply trying to do is read a value from my registry. I have been through several examples but can't get any of them to work. I've also tried running my application in Admin mode and still nothing. Can someone please help?
From all my examples that I've tried, I'll use the simplest one.
This works:
Dim val As String
val = Registry.LocalMachine.OpenSubKey("Hardware\Description\System\CentralProcessor\0").GetValue("Identifier").ToString()
MsgBox(val)
This (the one I want) doesn't:
Dim val As String
val = Registry.LocalMachine.OpenSubKey("SOFTWARE\PTSClient").GetValue("ConfigDB").ToString()
MsgBox(val)
THe latter path and value is one that I've manually created in the registry. I've checked the permissions between the two and they are the exact same. I've also tried running the app as administrator. I get a runtime error on the val= line, it says: Use the "new" keyword to create an object instance.
Any ideas? All the various online examples have failed and for the life of me, I can't figure out why...
Cheers,
J

Well, I have tried your code with a sample application compiled for x86 and, as expected, it fails with a null value exception.
I assume you are building an application for x86 mode and running in a 64bit environment.
Of course, if this is not the case, let me know and I will delete this answer.
In the situation outlined above, the calls to read/write in the LocalMachine.Software registry path will be automatically changed by the Operating System to read/write in the Software\Wow6432Node subkey and thus, your code is unable to find your manually inserted key ("SOFTWARE\PTSClient").
This code will give a null value as return from Registry.LocalMachine.OpenSubKey("SOFTWARE\PTSClient") leading to the failure to get the ConfigDB value.
You need to add your keys/values to the Software\Wow6432Node path or compile your application for AnyCPU mode or let your code write the value to the register (it will be redirected to the Wow6432Node).

Related

Getting Windows Service To Read Registry HKLM

I've been having a heck of a time trying to get this to work. I wrote both a service and a form application in VB.NET, both of which need to access a registry key to locate a computer that has my database on it. In the forms app it works great, but the service does not. I thought it was a permissions problem so I checked permissions on the server (Windows 2008) and they were fine - I even went as far as to run the service as the admin in case that was the problem but still no joy. Is there something wrong with my code?
I have tried ways to access the registry. The first method just sets the server variable to nothing and the second method the 'rk' variable ends up being nothing (telling me that it cannot even locate the sub key):
Dim server As String = My.Computer.Registry.GetValue("HKEY_LOCAL_MACHINE\SOFTWARE\EPS\XPV", "Server", Nothing)
and the second one is:
Dim rk As RegistryKey = Registry.LocalMachine.OpenSubKey("\SOFTWARE\EPS\XPV")
The service itself starts up just fine because I'm getting my log messages right after these lines that tell me the value is blank so it just comes down to figuring out why I cannot access the registry in the service even though I can in the forms app.
Either look under HKLM\SOFTWARE\Wow6432Node for your keys/values, or compile your application as 64bit.

Calling COM component method from IBM Notes 9 fails

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.

LsaAddAccountRights Custom Action Returning Error Code in Windows Server 2012

I have a custom action which is used to elevate users to be able to log on as a service. This gets run during the installer. It works fine for years on every Windows operating system up until Windows Server 2012. When the below code is run on this version of Windows instead of getting a long back of 0 for success I get a different error code back.
LsaAddAccountRights(
IntPtr PolicyHandle,
IntPtr AccountSid,
LSA_UNICODE_STRING[] UserRights,
long CountOfRights)
The problem is the code appears to be different every time and is a very large number, e.g. 102938473.
I run the error code through the following method to get the error code but this returns a different large number which doesn't appear to be a valid error code.
LsaNtStatusToWinError(long status)
I have tried looking these error codes up, but with no luck. They seem to be randomly generated and nonsensical.
If I ignore the returned error code, It appears that the user is successfully allowed to log on as a service. So everything appears to be working, except I am getting an error code back. I could ignore this error code, but what happens when it is a valid error, I may ignore it in the future.
Extra Information
I can run the code that is in the Custom action fine on its own in a console application without error. Only when it is part of the wix installer it seems not to work.
I'd take a look at the WiX Util extensions's User element. The name attribute can be a property. Using the CreateUser, LogonAsService and UpdateIfExists attributes you can take an existing account and grant it the rights. Or perhaps you have more code that you can refactor.
Issue could be with the return type of LsaAddAccountRights in C#.
I was able to solve the issue by changing the return type of LsaAddAccountRights in C# from long to UInt32. Found this information here . This change must be done for LsaNtStatusToWinError and LsaClose as well.

Editing Registry With VB

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.

Using /ApplicationPublicName does not change AppName() output

I know it's a long shot that there might be any uniPaaS developers on here, but here goes:
Today for the first time I've gone to duplicate a system we have in uniPaaS 1.5.
In the uniPaaS broker, I added the flag /ApplicationPublicName to change the
APPNAME that the application responds on.
However, the AppName() output that the application generates is still the
original name of the application, not what I specifying as the
ApplicationPublicName.
Our system relies heavily on AppName(). Is there any way to get AppName() to
return the same value as /ApplicationPublicName?
the AppName() function returns that application name as it was defined in settings, application.
If you want the appname to return something else, simply iniput that value to the Magic_Systems section of the ini file.
Better late than never to answer your own question I guess.
To work around this, we internally depreciated the use of the AppName() function, and instead replaced it with our own IntAppName(). Our new function does an INIGet('ApplicationPublicName') and returns that, as AppName() seems to always be fixed to the name of the application when it was compiled.
This was 4 years ago on 1.5 - perhaps v2.0 is different now, but we have continued to use our internal function without issue.