I am creating an new installation package for one of our products and I'm having significant trouble getting the event message description DLL to be used by Windows to provide event descriptions to the Event Viewer. I always get the following message in the Event properties:
The description for Event ID ( 39 ) in Source ( MyProduct) cannot be
found. The local computer may not have the necessary registry
information or message DLL files to display messages from a remote
computer. You may be able to use the /AUXSOURCE= flag to retrieve this
description; see Help and Support for details. The following
information is part of the event: MyProduct, , , , , , , , ,
MyProduct.
My previous installer seems to work fine on other systems. The target operating systems here are WinXP SP3 and Server 2008 R2 and I see the same issue on both. The event message file is registered under the Eventlog\Application key under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services with the EventMessageFile and TypesSupported present set to the correct values.
I have tried the following in an attempt to resolve the issue:
Moving the event message DLL to the System32 folder
making sure the Event Log service has full access to the event message DLL (2008 only - WinXP is not on a domain so does not have the Security tab in file properties.
Any ideas as I'm running out of options and can't find anything online other than to setup the registry, which I have done from the start.
In the end it turned out there was a compilation error in our Event Message DLL(!)
Related
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 have created outlook addin for Outlook 2013 64 bit.
In that Addin, i have created Form region with custom controls.
Then with the reference of http://blogs.msdn.com/b/emeamsgdev/archive/2013/11/21/outlook-deploying-an-outlook-2013-add-in-using-installshield-le.aspx i created setup file for Addin.
Now i installed it in my computer and everything works fine.
However when i try to install it on client computer, it doesn't show addin in outlook.
and i am not able to find any reason.?
I have also created registry for my addins
If it simply doesn't load, without errors, it only means one thing, outlook is unaware of your addin, cause even when addins are not working, outlook gives you an error or turns the LoadBehaviour regkey to '2'.
On your client, you should check that the registry values are set properly.
**HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\Outlook_PROJECT_ADDIN
If your addin doesn't work, check to see if those values exist, and if they do, what happens when outlook loads ? does LoadBehavior turns to '2' instead of 3 ?
If so, and it works perfectly on your pc, it probably means you have issues with the Manifest regkey, make sure the manifest points to a valid local location followed by a |vstolocal
so its syntax should be something like:
file:///C:/Outlook_Proj.vsto|vstolocal
Also make sure you have .Net Framework v4.0 installed on your target PC.
If you're trying to install it to a network drive, make sure you remove the '|vstolocal| thingy, and add the network drive to the trusted zone in Internet Explorer Settings.
Hope the following steps will help you solve this problem if you are still facing it.
Run the deployed setup with administration rights.
If it is not shown under Add-ins, open the setup folder and double click on the .vsto file then select install.
If you can see the addin among the others, and is not functioning it means it is disabled. To enable the add-in(since you are using outlook 2013), go to File -> Slow and Disabled Add-ins, and you shold see your add-in on the pop-upped window. Enable it.
Create the VSTO_SUPRESSDISPLAYALERTS = 0 enviorment variable to get any VSTO alerts. Take a look in the Windows event viewer and off course be sure of being installed the pre requisistes like Office Primary assembles and VSTO for office. Another think, check if your adding was not crashed once and move to inactive add-in list. Search registry for Resiliency key.
I have been searching the web and cannot seem to find a good answer on this.
I sort of understand the cause but need some help on the solution.
I use the following command to export windows system logs. I want/need them to be in evtx format for later use.
wevtutil epl system c:\SystemEvents.evtx
The goal is to send them to other people which will not be viewing them on the same server.
This of course cause the full event text to not be part of the exported log and the user will see something like this:
The description for Event ID XXX from source Server Administrator
cannot be found. Either the component that raises this event is not
installed on your local computer or the installation is corrupted. You
can install or repair the component on the local computer.
If the event originated on another computer, the display information
had to be saved with the event.
The following information was included with the event:
I was reading this page:
http://technet.microsoft.com/en-us/library/cc749339%28WS.10%29.aspx
and found this snip of info in it:
To troubleshoot events that were logged on a remote computer, you must
export and archive the log with the display information. The display
information for the saved events is stored in the LocaleMetaData
folder and should be moved with the log information when the
information is viewed on another computer.
I do not understand what location (or process) this statement is referring to.
There is no LocaleMetaData folder anywhere on the server so I am assuming that I need to somehow create and export some additional data along with the evtx file for it to then re-merge back on the viewing system.
Am I on the right track here and could someone tell me how to fully export the event log this with will full verbose messages?
I found the answer:
When you use this:
wevtutil al <FileName.evtx> [/l:<LocaleString>]
to export... the location of where the .evtx folder ends up, there will be a LocaleMetaData folder created with the .MTA file inside.
try this one out:
This explains the step to use Event Viewer to export windows log event .
https://www.ibm.com/support/pages/exporting-windows-event-logs-event-viewer
I have Test controller and Test agent installed on a virtual machine VM1. Test agent is shown is Online. I'm trying to run CodedUI tests remotely from my machine. But every time I go to Test -> Manage Test Controllers... in VS2010 it hangs. The same effect when I try to run any test remotely.
Both machines are in the same domain, on my machine i'm using domain admin user, on VM local admin.
I've got these 2 errors in Event Viewer:
The description for Event ID 0 from source VSTTExecution cannot be
found. Either the component that raises this event is not installed on
your local computer or the installation is corrupted. You can install
or repair the component on the local computer. If the event originated
on another computer, the display information had to be saved with the
event. The following information was included with the event:
(devenv.exe, PID 7732, Thread 1) IdleProcessorManager.DoWork - Job
threw: Item has already been added. Key in dictionary:
'7c58e17b-57a5-e486-31cc-aca08ec38d23' Key being added:
'7c58e17b-57a5-e486-31cc-aca08ec38d23' at at
Microsoft.VisualStudio.TestTools.Common.Xml.XmlPersistence.LoadHashtable[K,V](XmlElement
element, String location, String keyLocation, String valueLocation,
XmlTestStoreParameters parameters) at
Microsoft.VisualStudio.TestTools.Common.TestListCategory.Load(XmlElement
element, XmlTestStoreParameters parameters) at
Microsoft.VisualStudio.TestTools.Common.Xml.XmlFilePersistence.LoadTestList(String
fileName) at
Microsoft.VisualStudio.TestTools.TestManagement.Tmi.LoadCategories(String
location, TestListCategoryConflictHandler idVetoingHandler,
TestListCategoryConflictHandler nameVetoingHandler) at
Microsoft.VisualStudio.TestTools.TestManagement.Tmi.LoadCategories(String
location) at
Microsoft.VisualStudio.TestTools.TestCaseManagement.SolutionIntegrationManager.LoadCategoriesIntoTmi(String
filename) at
Microsoft.VisualStudio.TestTools.TestCaseManagement.SolutionIntegrationManager.d__83.MoveNext()
at
Microsoft.VisualStudio.TestTools.TestCaseManagement.IdleProcessorManager.DoWork()
The description for Event ID 0 from source VSTTExecution cannot be found. Either the component that raises this event is not installed on
your local computer or the installation is corrupted. You can install
or repair the component on the local computer. If the event originated
on another computer, the display information had to be saved with the
event. The following information was included with the event:
(devenv.exe, PID 7732, Thread 65) Timed out waiting for controller
connect
The answer was given here http://social.msdn.microsoft.com/Forums/en-US/vststest/thread/4e8445e6-5c35-4c33-820e-0c334046631b?prof=required
Running Visual Studio in Safe mode solved the problem.
I resolved this problem by installing update 2 of Visual Studio.
I got a similar exception (see bellow).
There was a run setting configured and used from my project solution under
"Visual Studio/Test/Configure Run Settings/"
So I unchecked and it was working again...
Under Configure Run Settings, now I have :
a "Checked Auto Detect runsettings Files"
and the "Select Solution Wide runsettings File entry"
and the unchecked "project.testsettings" file.
The description for Event ID 0 from source VSTTExecution cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
(testhost.x86.exe, PID 10320, Thread 3) TestTypes\{7a24f8ff-85da-d664-ef44-83ff4743dae6} could not be loaded because the TIP could not be instantiated for the following reason(s): An item with the same key has already been added.
The message resource is present but the message was not found in the message table
I have a VB6 application, the installer is compiled using INNO Setup.
The installer runs fine. But in about 10% of computers when the user clicks the Icon to run the installed app, it doesn't start, no error message, only a Beep sound.
This is happening on XP and also Win 7.
I develop in XP and Win 7 and the application works OK, so I haven't been able to reproduce the issue.
The installer registers all ocx and dlls needed (afaik). (Well not completely all, it assumes MS run-time components should be there, but I guess an error message should show up if something is missing)
I was thinking some kind of user permissions, UAC, but even users in the admin group have had the issue.
Could you point me to what possible issues to look for and test in order to patch the app.
Thanks!
[FOLLOW UP]
Thanks to the tips, found out the manifest is causing the problem. I use it to make the controls look better:
http://www.vbaccelerator.com/home/vb/code/libraries/xp_visual_styles/using_xp_visual_styles_in_vb/article.asp
Now I'm trying to discover why. I have another application with the same manifest and that one works ok.
Haven't been able to get feedback on the event viewer yet.
The "beep crash" often points to an error in an application manifest such as an XML syntax error or namspace conflict. Event Logs will often provide a hint about this.
But I've found that people often try to use the Common Controls 6.0 Library without ensuring proper library loading sequence.
Before any Forms are openend you should load shell32 and then comctl32. The easiest way is a couple of no-op calls in Sub Main:
Option Explicit
Private Declare Sub InitCommonControls Lib "comctl32" ()
Private Declare Function IsUserAnAdmin Lib "shell32" () As Long
Private Sub InitCommonControlsVB()
IsUserAnAdmin
InitCommonControls
End Sub
Private Sub Main()
InitCommonControlsVB
Form1.Show
End Sub
Without this your program will usually work fine in Vista or Win7, but will fail on some XP service pack and patch levels. Part of this is due to changes over time in the Fusion subsystem that handles SxS activation and comctl32.dll patches.
Ignore those saying you need to call InitCommonControlsEx(), it isn't necessary unless you are constructing and using Win32 controls directly instead of VB6 and COM controls.
A few things to try to narrow it down:
Check the Windows Event Log for crash events
Check the Windows Event Log (in the Application section) for crash reports from your application. You can quickly get to the log viewer on Windows XP by clicking Start > Run, typing eventvwr and pressing Enter. On Windows 7, you can type "event viewer" in the search box that is in the Start menu. You can filter the events to only show error events from your program.
You might find a few error events on one of the computers where this problem has already occured, because it sounds like the error reporting feature is turned off on these computers (in which case "hard crashes" like access violations are logged in the Event Log instead of displaying an error dialog to the end-user, as long as a debugger isn't installed on the computer).
Make sure "Error Reporting" is turned at the OS level
As mentioned in the previous section, it sounds like the error reporting feature is turned off on these computers. In that case, a crash won't display any kind of message to the end-user at all and the application will just vanish suddenly. In Windows XP, you can check this setting (and turn it on) as follows:
Right-click "My Computer" and select Properties.
Open the Advanced tab and click the Error Reporting button.
Select the Enable Error Reporting option.
Click OK to all the open windows.
Add trace code to your application
You could also add some trace code to your application's start-up code, such as code to display a message box or write a message to the Windows Event Log or to a log file as soon as your application starts (for example, in the Form_Initialize event of your main form, or in a Sub Main routine).
This way you will be able to tell whether your application is crashing before or after the VB6 runtime is loaded: if you try to start the application and it disappears/crashes, and your startup message isn't logged, then you know it's crashing before it even has a chance to get to your application's startup code, which could indicate that a dependency of the VB6 runtime or the VB6 runtime itself is not installed properly.
Note that Windows XP and Windows 7 both ship with the VB6 runtime pre-installed, but it's possible for misbehaving installers to overwrite or remove files that are part of the VB6 runtime.