Running on Windows 7 and Server 2012, I have a VB.NET app that uses the System.Diagnostics.EventLog collection of log entries. When I retrieve one particular Security event log entry's Message property I have a bunch of text that looks like "%%2048" instead of something like "Account Enabled". See the snippet below:
User Account Control:
%%2048
From what I have discovered, this may be a "replacement string" that is a kind of place holder for another string. This is new to me and I would like to know how to translate these codes into their final value. When I use the Event Viewer application the final text ("Account Enabled") is visible instead of the numeric equivalent so I know that the translation is possible.
I have seen some posts that talk about using a different class (EventLogRecord) but I have not seen enough that helps me. Can anyone provide an example of how to get a properly formatted event log entry message?
I wound up trying out the EventLogRecord class. Using the FormatDescription method gave me the properly formatted event message body I was hoping for. It just took quite a bit of trial and error to figure out how to use this class as well as how to format a very basic EventLogQuery string (I was trying to avoid using a query string). The only examples I saw of a query string were very complex (to me) and I just wanted a plain old select all records with no filtering. Fortunately, it only took a couple of tries to stumble upon the right brief syntax.
From what I can tell, the old method worked fine for Win XP and Server 2003 (the OS's that the application had been running on). I am now porting it to Windows 7/Server 2012 and apparently the OS has started using the placeholders in the message body in the newer OS's. The EventLogRecord is specifically for these newer OS versions and as such has the features you need to format the message properly.
Related
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.
I am the IT department of a Non-Profit organization. I have a question today which might be too specialized for this forum and I hope I do not waste my time writing it up. We are using Blackbaud's 'Raiser's Edge' (RE) Software (written in VB6 and VB.net as far as I know) to keep track of our membership and donations. We have an MS Access application (have been using it since before we got RE) to process donations and for now I want to keep it and only do minor changes to adapt it to the new software.
The MS Access program is now doing a few calls to the RE API which work great. To login and establish a connection I have to create a new 'REAPI' object and use it for other API calls. That REAPI object has a method called: SignOutOnTerminate which needs to be set to TRUE when creating that object. It is supposed to kill all connections to RE once my application closes. There is no regular .close method.
Once I create the object I can do work as many times as I want and there is no problem at all as far as I can see.
However when trying to close the application or set the object to nothing (Set REAPI = Nothing) Access crashes immediately (It fades out and I get the message that Windows is looking for a solution to the problem. Then Access closes and restarts itself.)
It is more annoying and unprofessional then hindering production but I want to fix it.
The App was developed on Windows 7 64-bit with Access 2010 32-bit. It was tested on Windows XP with Office 2003 or 2007 machines (32-bit) and behaves the same way.
I have posted this problem already on 2 Blackbaud forums and tried a suggested a work around which did not work (kill the process with a shell command and then set the object to nothing). Hopefully I will get more answers soon.
I tried to just exclude the SignOutOnTerminate when creating the object. But got the same behavior.
I looked in the Event Manager --> Application Log and found the Crash. It reported that access crashed because of this dll: C:\Windows\System32\MSVBVM60.dll (It is actually located in the SysWos64 folder as it is a 32-bit application).
Looking up this error I found some suggestions to replace it with an earlier version of the dll, the one which ships with XP. I found a file and tried the suggestion but it still crashed. The error log reported the older version number as faulting so I registered it correctly.
I also created a case with Blackbaud but the rep did not know what the problem is and did not have MS Access installed. He is trying to get his support team to install it for him so he can test and investigate this error.
The last suspicion I have is that the API is causing the error and my code is fine.
But before I make this assumption and until I get my answer from Blackbaud I want to do a final check, but I have run out of ideas for further trouble shooting and resorted to pose this problem in this forum.
Any Ideas?
I realise that this is an old thread and if you have solved this by now then that is great. However this is a known issue with The Raiser's Edge API. If you use .NET with RE's API (which is COM based) there is definitely some resource that is not cleaned up properly. At one point I suspected that it was something to with making use of RE's graphical interface i.e. by calling the regular login method to log you into RE. However even if you log in to RE using the "as a server" method supplying the user name and password it still crashes on exiting the application.
We have an installer that sets up credentials in RE. The installer is in .NET and accesses the RE API. We now show a message just before the end of the application telling users to ignore the impending crash... Not a great solution by any means.
In my winrt app, I am trying to update the live tile based on polled URIs. There is currently no update happening and I can't figure out how to troubleshoot. There are numerous scenarios that could be breaking things but i can't seem to find anyway to get insight into potential errors.
The TileUpdateManager seems to be a bit of a black hole that absorbs information but never lets it out.
Does anyone know of how to view errors from the TileUpdateManager?
If it interests anyone, here is my update code:
TileUpdateManager.CreateTileUpdaterForApplication().EnableNotificationQueue(true);
PeriodicUpdateRecurrence recurrence = PeriodicUpdateRecurrence.HalfHour;
List<Uri> urisToPoll = new List<Uri>();
urisToPoll.Add(new Uri(#"http://livetileservice2012.azurewebsites.net/api/liveupdate/1"));
urisToPoll.Add(new Uri(#"http://livetileservice2012.azurewebsites.net/api/liveupdate/2"));
TileUpdateManager.CreateTileUpdaterForApplication().StartPeriodicUpdateBatch(urisToPoll, recurrence);
To expand on Nathan's comment, here are two steps you can take to troubleshoot:
Enter your URI straight into a browser to see the results that are returned, and inspect them for being proper XML. As Nathan points out, your URIs are returning JSON which will be ignored by the tile update manager. As a working example (that I use in Chapter 13 of my HTML/JS book), try http://programmingwin8-js-ch13-hellotiles.azurewebsites.net/Default.cshtml.
If you feel that your URI is returning proper XML, try it in the Push and Periodic Notifications Sample (Scenarios 4 and 5 for tiles and badges). If this works, then the error would be in your app code and not in the service.
Do note that StartPeriodicUpdate[Batch] will send a request to the service right away, rather than waiting for the first interval to pass.
Also, if you think that you might have a problem with the service, it's possible to step through its code using Visual Studio Express for Web running on the localhost, when the app is also running inside Visual Studio Express for Win8 (where localhost is enabled).
.Kraig
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).
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.