When I try to run my Windows Store app, it won't, and shows me this:
..."does not support the contract specified"? What contract? I'm not implementing any contract; I assume it means the Settings contract or some such, but I'm not doing any of those yet.
I went to the Help page suggested, and it says, in part, "To diagnose these errors
There are no sure ways to fix these errors. Use these techniques to diagnose the problem."
The first suggestion is:
Open Event Viewer (on the Windows Start menu, search for Event Viewer.) In Event Viewer, navigate in the tree to the Application and Services Log\Microsoft\Windows\Apps folder.
Filter the view to event Ids: 5900-6000
Examine the log and see what occurred.
Windows 8.1 only brings up web pages when I search for "Event Viewer"
Actually, I did write a utility to catch event logs, and I ran that. I found these:
***Type: Error
Source: Microsoft-Windows-Immersive-Shell
Time Generated: 11/27/2014 15:10:39
Message: Activation of app App.adaf78a74.a8c80.a4ff5.a99ca.a97636d548196_8wekyb3d8bbwe!Designer.App failed with error: -2144927148 See the Microsoft-Windows-TWinUI/Operational log for additional information.
Type: Error
Source: Microsoft-Windows-Immersive-Shell
Time Generated: 11/27/2014 15:20:08
Message: Activation of app axXAndSpace.Visits_qtyjefqf75sa6!App failed with error: -2144927148 See the Microsoft-Windows-TWinUI/Operational log for additional information.***
But where is "Microsoft-Windows-TWinUI/Operational log"?
The second suggestion on the Help page was:
Use the native debugger
Configure the project to run under a native debugger.
In Visual Studio, set the Debugger Type to Native Only on the Debug (Debugging in C++ and JavaScript) page of the property pages of the start-up project.
Look at the exceptions being thrown by looking at the output window. You might want to configure the debugger to stop when these exceptions are thrown.
I did that, but it gave me no more information than previously - nothing at all displays in the Output pane.
What could be the cause of this?
UPDATE
Just to update the progress:
Based on Iris Classon's suggestions, I went to Control Panel to see if my app was installed so that I could uninstall it, but it's not in that list.
If I search for the app by typing its name, it tries to start up - its splash screen displays, but goes no further than that.
I went to Program Files\WindowsApps, and when selecting it got, "You don't currently have persimmons to access this folder, click continue to continually get access"
That leads me to "You have been denied permission to access this folder; to gain access to this folder, you will need to use the security tab"
Click the "security tab" link takes me to that tab, and a "For special permissions or advanced settings, click Advanced"
I do so.
That takes me to a Permissions tab, which says, "You must have Read permissions to view the properties of this object; Click continue to attempt the operation with administrative permissions"
I then selected (one at a time, as that is all it allows):
Trusted Installer : Full control
System: Read, Write, and Execute
System: Full Control
Administrators: Read & Execute
But so far, none of that seems to do anything good.
UPDATE 2
This problem has just "gone away" today; I don't think it was anything I did. I added a UserControl, tried running the app again, and now it runs - I don't see that error message. However, I do see a seemingly unrelated one. (at least I got further).
I just had this problem on a fresh install of Windows 8.1 on my laptop. I'm not sure which one of these steps solved it, but until somebody can give you a more exact answer here is something to try as I am sure you are keen on coding.
Only Store Apps run from VS gives that error, other Store apps work fine.
I first of all changed permissions on my WindowsApps folder under Program Files and made sure that I had full access to the folder and sub folders. Restarted the laptop, still no luck.
Then I set up an admin guest account (just something I tend to do for when I need to record tutorials- so not related to trying to solve the error). Out of curiosity I tried to create and run the same Windows Store App and got an error that another user had installed the app. Strange, how was it installed if it gave me the error that it couldn't activate the app on the main account?
I logged back in as the main user and uninstalled the application (which was showing up as installed), and I can now run any Store App from VS without problems.
Not sure this is an answer since I'm not sure what made it work, but give it a try and hopefully somebody else can clear this us up. I'll investigate further, but I'm on a train right now with poor WiFi connection :)
Best of luck!
I had the same scenario, here are the steps I did to resolve:
I tried to create packages, chose not to associate with the store.
It said that the certificate is expired, I created a new test certificate.
I created the test packages successfully.
Tried to run the project from VS and it finally ran.
I believe all of this had to do with the certificate. very frustrating and time wasting issue.
I also had the same problem and following steps fixed it. Hope it will help some one else.
Open the appxmanifest file
Go to "Packaging" tab
Select "Choose Certificate" and select "Pick from certificate store" and select your cetificate and click on ok
Related
I've just installed Octave 7.1.0 and I noticed a strange sequence of error/warning messages which I had never seen before nor am able to decipher:
2022-05-06T16:59:34.366ZE [6832:ShellIpcClient] message_loop.cc:133:Run Run called on MessageLoop that's already been Quit!
2022-05-06T16:59:34.368ZE [12660:ShellIpcClient] message_loop.cc:133:Run Run called on MessageLoop that's already been Quit!
2022-05-06T16:59:34.369ZE [8132:ShellIpcClient] message_loop.cc:133:Run Run called on MessageLoop that's already been Quit!
2022-05-06T16:59:34.371ZE [15212:ShellIpcClient] message_loop.cc:133:Run Run called on MessageLoop that's already been Quit!
Since I haven't had the time to test this new version (a mere 1/2 hour has passed since I installed it) I cannot tell whether or not Octave's functionality is compromised.
Any ideas?
Wherever this message comes from, it is not from Octave. Someone reported the same issue last year on Octave's forum at Strange opening messages when opening Octave each time which links to a similar issue on the Far Manager bug tracker. The Far Manager devs suggest that this comes from Google drive:
When you open a context menu, all registered shell extensions are loaded into the Far process. These extensions implement custom context menu items, shown by various software. Sometimes the authors of these extensions add various debug logging messages to their code to see what is going on in various situations. Sometimes these authors are too lazy to implement a proper logging and they just print stuff to the standard output stream, connected to a console. Windows Explorer doesn't have a console attached to it, so all these messages go into the void. Far, on the contrary, does have a permanently attached console - you're looking at it. Therefore, any debug stuff these lazy people print in their extensions ends up in that console.
It's quite sad, but there's nothing we can do about it.
Please search for that string ("Run Run called on MessageLoop that`s already been Quit") in your Program Files folder and, once found, report to the corresponding product owners. I suspect that in your case it's Google Drive.
I am new to the Design Automation API, so please excuse and correct me if I am using the wrong terms. I am setting up the wiring for my very first Design Automation AppBundle, and I have almost all of it working. I followed the patterns in the "Delete Walls" tutorial.
I have a working add-in DLL that I can test locally and it runs under the "design.automation-csharp-revit.local.debug.tool".
I also have all of the Rest API connections setup, and I can successfully submit a WorkItem that will download a Revit file from a BIM 360, and start processing it in the sandbox of Design Automation. But I am getting an error during the execution on the sandbox where it seems it can't find my add-in file. Here is an excerpt from the WorkItem log:
[07/21/2020 18:02:26] Resolving location of Revit/RevitCoreEngine installation...
[07/21/2020 18:02:26] Running user application....
[07/21/2020 18:02:31] Cannot find the addin file:
[07/21/2020 18:02:31] Fail to deploy Addon DLL(s) in AppPackages.
[07/21/2020 18:02:31] RESULT: Failure
I have looked through "bundle" ZIP file many times looking for typos that could cause this, but I can't find anything, it looks identical to the "delete walls" example. So I'm wondering if there is somewhere else that I need to look. Or any other way I could debug this to find out were the connection is missing. I can only assume that the AppBundle and Activity items are setup correctly since I am getting this far and the error is not mentioning either of those items.
Any tips on where to look?
This turned out to be a misspelling of the [dot]bundle folder extension that triggered the issue.
During packaging the Windows Store application, I get an unspecified error [APPX1204]:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\AppxPackage\Microsoft.AppXPackage.Targets(1139,9): error APPX1204: Failed to sign 'D:\Projects\VS2012\Stroik\Stroik\AppPackages\Stroik_1.0.0.11_AnyCPU_Test\Stroik_1.0.0.11_AnyCPU.appx'. SignTool Error: An unexpected internal error has occurred.
Build output refers to the part of a file generated by VS2012:
<SignAppxPackage AppxPackageToSign="#(FinalAppxPackageItem)"
CertificateThumbprint="$(PackageCertificateThumbprint)"
CertificateFile="$(PackageCertificateKeyFile)"
HashUri="$(_HashUri)"
EnableSigningChecks="$(EnableSigningChecks)"
>
<Output TaskParameter="ResolvedThumbprint" PropertyName="ResolvedThumbPrint"/>
<Output TaskParameter="AppxPackagePublicKeyFile" PropertyName="AppxPackagePublicKeyFile" />
</SignAppxPackage>
Yesterday packaging proceeded successfully. Today I added aditional logic to my app and changed some data in manifest. Since then I'm reciving presented error. I tried to regenerate Certificate in Packaging menu, delete Store/Temporary Keys (then regenerate), ... much more but nothing helps.
Now I have no idea how to handle it. Furthermore packaging a new project (as it is provided by vs2012) results in the same error.
Have you got any suggestions how to solve it.
If it helps anyone else, I was trying to make the build on a network share (virtualizing windows). Creating it on the Windows partition solved the issue.
I was developing on a Virtual Machine in VirtualBox and tryed to publish to the shared folder.
Change the output folder to a local folder on the virtual maschine solved it.
Granted this is older - see if you can try it with a different live id
You could also try to generate a new app, and diff the manifests between the apps.
Now according to:
http://social.msdn.microsoft.com/Forums/en-US/toolsforwinapps/thread/f25939fb-c48c-4bd0-938e-6a0afbd2dca0/
you may want to sign out, use IE 'in safe private browsing' and create a new one.
Also ensure that IE is set in "Browsing History->Settings" to get a new version of the page every time.
Login with the new one and give it a try.
I'm not sure if this error is related here or not, but it's a starting point based on the prior feedback on the above post.
This japanese site lists the same error code and seems to have the same resolution as well
http://coelacanth.heteml.jp/blog/windows-8signtool-error-an-unexpected-internal-error-has-occurred/
Its worth a shot, but I'll admit on this one not being 100% sure, just trying to help out : )
For some weeks now we have been fighting with an issue where at a small number of customers our Outlook addin gets unloaded and disabled for yet undetermined reasons. By "disabled" I mean that Outlook changes the following registry value from 3 to 2 which in effect means that the addin will not be loaded on next startup:
HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Outlook\Addins\[OurAddin.sProgID]\LoadBehavior
There is no error message and neither do any exceptions show up in the log files that our addin produces itself.
I have already found the following page which specifically deals with the LoadBehavior change issue: http://blogs.msdn.com/vsod/archive/2008/04/22/Troubleshooting-com-add-in-load-failures.aspx
However, none of the possible reasons proposed there appear to be applicable:
The addin is not merely listed in the Disabled Items list.
There are no unhandled exceptions neither in the IDTExtensibility2 methods nor anywhere else in the code. All code is wrapped in try/catch equivalents and all exception output is emitted only via OutputDebugString or into a log file.
The error appears to be independent of anti-virus software, i.e. it also occurs with it disabled.
Disabling all other addins also has no effect on the error.
So, what else can cause Outlook to disable an addin?
Some more details / observations:
We haven't been able to reproduce the issue in our test environments so far so we haven't yet been able to attach a debugger while the issue occurs.
The issue never occurs while we try to watch what happens via remote support (TeamViewer). I suspect this is because TeamViewer uses a hook DLL that injects itself into all running processes (including Outlook) and thus affects the memory layout, timing, thread order, whatever.
Whenever we compile a new version of the addin to try out something new the addin will typically work fine for a couple of hours or even days only to eventually get disabled again. Once this has happened all subsequent attempts to get the addin to load on that machine (by manually changing back the LoadBehavior value) will fail (i.e. LoadBehaviour will simply change back to 2) until we compile and deploy another build (or try to watch using TeamViewer - see above).
Typically the addin will get unloaded right on Outlook startup though occasionally it also does happen after Outlook has already been running for some time. The log file in those cases looks completely inconspicious - the addin simply goes through the regular shutdown steps just as if Outlook had been closed normally.
As far as I can tell from our log files and by observing the issue via SysInternals ProcessMonitor, when the addin get disabled on Outlook startup (rather than during the session) the DLL gets unloaded even before the COM object (i.e. the addin) gets instantiated (log messages in the constructor never show up).
We have put OutputDebugString messages in initialization sections (this a Delphi DLL). None of them show up when the addin fails to load.
Only a very small fraction of our customers is affected by this issue. We have several tens of thousands of installations from whom we haven't received any reports about this.
UPDATE: It seems that often (but not always) one of the last things that gets logged before the addin gets unloaded is an exception with text "OLE error 800A01A8". That exception gets caught by a global exception handler built into the framework I'm using (Add-in-Express) and does not appear originate from anywhere it my own code every single method of which is by now entirely wrapped in try..catch. This typically occurs right after I set the visibility of my CommandBarButtons from an Inspector's Activate event handler.
Common properties of all affected machines:
Windows XP Professional, up-to-date patch level
Outlook 2003 Professional, up-to-date patch level
varying versions of McAfee Virus Scan (though disabling it has no effect - see above)
Users are members of the local Administrators group
One more thing to note which very probably is significant as well (though maybe not as much as I first thought):
We are using a licensing / copy protection module from a third-party vendor which wraps the compiled DLL in a "shell" and only unpacks it on-the-fly. Ever since I found out that the addin gets unloaded even before any of our own code gets executed this has been my prime suspect. However, while the vendor confirmed that there may be unhandled exceptions in their code a log file produced by a special debug version of the protection shell showed that the unpacking process completed successfully and control was already handed back to the protected DLL before Outlook unloaded the addin. So it appears that whatever causes Outlook to unload our addin happens between the completion of the protection shell's initialization and our own code.
Any more ideas?
My company has been putting up with what sounds like the same issue you are seeing for years. The plug-in we have is a VB6 COM add-in for Outlook 2003 and it’s deployed on several hundred machines that get cycled hundreds (if not thousands) of times a day. We go through the load and unload cycles a lot.
We get a fair bit of the general errors where the plug-in is loaded but not connected and we handle that in code. (Obviously not production quality)
Dim outlook As outlook.Application
Set outlook = CreateObject("Outlook.Application")
outlook.COMAddIns("MyFancyDancyPlugin").Connect = True
Rarely, but not so rare that it isn’t an annoyance, we see the plug-in reach a state where it is loaded and we can see it in “Tools>Options>Others>Advanced Options> Com Add-Ins”, but we just can’t connect to the thing. If you try to connect you don’t get an error it just switches back to disconnected. [The equivalent of switching back to a 2 in the registry key] The COM object as far as I can tell is never created. The item is not listed in the Disabled items.
We don’t actually have to redeploy to correct this error. Removing the object through the Com Add-Ins dialogue and then re-adding it there seems to correct the issue. This is still not an acceptable solution but it does get things back and running without a reinstall.
Windows XP Professional, up-to-date
patch level
Outlook 2003
Professional, up-to-date patch level
varying versions of McAfee Virus Scan
(though disabling it has no effect -
see above)
Users are members of the
local Administrators group
This seems to fit, we don't use McAfee but the virus scanner also doesn't interact with outlook or the com add-ins. We also don't use a copy protection app.
I'm sorry I can't be of more help, but I would love to root cause this.
I am also working on Outlook Add-In and I know one reason when the Add-In gets disabled. some time when Outlook shuts down abruptly or user forcefully shut down the Outlook, add-In gets disabled. I am not sure if this is the reason in your case but it could also give you some direction to think of.
I some time use this method (closing the outlook using task manager while it is still loading) to simulate this behavior and actually I have developed a tool which scans all the machines provided to it and checks if the add-In is disabled on a machine and if yes it changes the registry value to enable it.
maybe you are a lockback policy victim. add a bypass key to registry, then it works.
modern office versions or vsto creates the key while installation. the effect is: install
a modern office too and the adddin now are also loaded in older office. please take a look
code snippet taken from NetOffice http://netoffice.codeplex.com
public static void RegisterFunction(Type type)
{
try
{
// add codebase value
Assembly thisAssembly = Assembly.GetAssembly(typeof(ExampleClassicAddin));
RegistryKey key = Registry.ClassesRoot.CreateSubKey("CLSID\\{" + type.GUID.ToString().ToUpper() + "}\\InprocServer32\\1.0.0.0");
key.SetValue("CodeBase", thisAssembly.CodeBase);
key.Close();
key = Registry.ClassesRoot.CreateSubKey("CLSID\\{" + type.GUID.ToString().ToUpper() + "}\\InprocServer32");
key.SetValue("CodeBase", thisAssembly.CodeBase);
key.Close();
// add bypass key
// http://support.microsoft.com/kb/948461
key = Registry.ClassesRoot.CreateSubKey("Interface\\{000C0601-0000-0000-C000-000000000046}");
string defaultValue = key.GetValue("") as string;
if (null == defaultValue)
key.SetValue("", "Office .NET Framework Lockback Bypass Key");
key.Close();
// add addin key
Registry.ClassesRoot.CreateSubKey(#"CLSID\{" + type.GUID.ToString().ToUpper() + #"}\Programmable");
Registry.CurrentUser.CreateSubKey(_addinRegistryKey + _prodId);
RegistryKey rk = Registry.CurrentUser.OpenSubKey(_addinRegistryKey + _prodId, true);
rk.SetValue("LoadBehavior", Convert.ToInt32(3));
rk.SetValue("FriendlyName", _addinName);
rk.SetValue("Description", "NetOffice COMAddinExample with classic UI");
rk.Close();
}
catch (Exception ex)
{
string details = string.Format("{1}{1}Details:{1}{1}{0}", ex.Message, Environment.NewLine);
MessageBox.Show("An error occured." + details, "Register " + _addinName, MessageBoxButtons.OK, MessageBoxIcon.Error);
}
}
If you have the ability for your users to run a debug program to get more information about the problem when it happens, try using Add-in Spy from Microsoft.
http://msdn.microsoft.com/en-us/library/cc984533(v=office.12).aspx
I was having an add-in fail to load and discovered that it was happening because a dependency wasn't getting preloaded. This tool should be able to tell you what specific error is happening when the Outlook add-in fails to load.
Just to close this up: The problem did eventually turn out to be caused by a bug in the third-party licensing wrapper we were using. It has been confirmed by the vendor and was fixed in more recent releases.
We have an error that we can't seem to find and don't have the need/resources to try and track it down. What we do need to do is just keep the freaking "Please tell Microsoft about this problem" dialog boxes from cluttering up the server.
It is from an MS-Access error (we think) but I can't find where Access is installed (I don't think it is); there is no MS Office directory on any of the drives.
If we could just stop the dialog boxes from appearing that would be great.
Thanks.
Spec: Window Server 2003 sp2
From http://www.codeproject.com/KB/exception/UnhandledExceptionClass.aspx:
If you also want to disable the Windows “Send Error Report” dialog on your computer, right-click on the “My Computer” icon, select “Properties”, switch to the “Advanced” tab, and click on the “Error Reporting” button. In the Options dialog, select the “Disable error reporting” radio button:
Compare also http://www.codeproject.com/KB/exception/ExceptionHandling.aspx for general .NET Exception Handling sanity.
I don't think you realize jusy how serious this error might be. These errors pop up under severe conditions like buffer overflows, null pointer dereferences, division by zero errors, etc. Given that you mentioned that this runs on a server, you potentially (depending on your situation) have a network facing, easily exploitable program!
As others have suggested, you can turn off error-reporting system wide, or you can use the SetErrorMode API to disable it for just your application, but again I would strongly advise to investigate and fix the problem at its root!
Well, I would try and figure out what application is using Access. Not knowing what is running is a real issue, especially when it is having unhandled exceptions!
As far as just disabling?
Try:
Right click 'My Computer'
left click 'Properties'
left click 'Advanced' tab
left click 'Error Reporting' (near bottom)
left click 'Disable error reporting'
It's called the Windows Error Reporting Dialog. You can disable it by following these instructions:
http://www.windowsnetworking.com/articles_tutorials/Disable-Error-Reporting-Windows-XP-Server-2003.html
However, I would be concerned with why you are getting those error messages. You are just concealing a problem which could be very bad.
Since I see three different people posted instructions on how to disable the dialog on their own machine, I'll post this again as an answer instead of just a comment:
They don't want to do that on their customer's machines, because that will disable any application from using the dialog. They just want to prevent it from coming up for their application.
It's not concealing anything, if a program crashes windows will still tell you. The difference is that it won't compile a core dump and try to send it to microsoft for you. It's very useful to disable this garbage.
When working in .net, you can catch all unhandled exceptions (which is what causes this message). But I'm not aware of a way to do the same in Access.
http://devcity.net/Articles/60/1/unhandled_exceptions.aspx