I have an internal web chat application implemented in python/django and using ejabberd 2.1.3 and Strophe.js.
When you open the website with a special access link, a cmd line call is executed to add you to a shared roster group:
ejabberdctl srg_user_add 00024-540-1mCYpYTTCRcjJK5OWI7cWs xmpp.mydomain.com
1mCYpYTTCRcjJK5OWI7cWs xmpp.mydomain.com
The executes successfully and if I execute this cmd manually the members are shown fine:
ejabberdctl srg_get_members 1mCYpYTTCRcjJK5OWI7cWs xmpp.mydomain.com
00024-540-1mcypyttcrcjjk5owi7cws#xmpp.mydomain.com
01114-540-1mcypyttcrcjjk5owi7cws#xmpp.mydomain.com
However, in the Strophe.js presence handler I only receive a presence stanza for myself, meaning if I open two different links in two different browsers for two different members, I do not receive a presence stanza for the other member.
If set the ejabberd log level to debug, this is reflected here.
<presence xmlns='jabber:client' from='0031-666-vjuuogji8mxvo5edtsvre#xmpp.mydomain.com/3189433061352390311794558' to='0031-666-vjuuogji8mxvo5edtsvre#xmpp.mydomain.com/3189433061352390311794558'/>
<presence xmlns='jabber:client' from='0030-666-vjuuogji8mxvo5edtsvre#xmpp.mydomain.com/3319710041135238652858307' to='0030-666-vjuuogji8mxvo5edtsvre#xmpp.mydomain.com/3319710041135238652858307'/>
It's missing the stanza to the other member:
<presence xmlns='jabber:client' from='0031-666-vjuuogji8mxvo5edtsvre#xmpp.mydomain.com/3189433061352390311794558' to='0030-666-vjuuogji8mxvo5edtsvre#xmpp.mydomain.com/3319710041135238652858307'/>
I have the same setup on a second server where it works fine, and I see the stanzas exactly as expected.
Before, it also worked on the problem server, but last week we had a total power failure in the data center and the server went down. Since then I cannot seem to get it to work again.
Could it be that some files might have been corrupted due to the power loss? Is there something I should clean up?
Unfortunately the previously responsible person is no longer in our company...
I found the problem - due to some stupid internal reasons, the
ejabberdctl srg_create ...
was missing, so the members were added to a non-existent group.
I just do not understand why the srg_user_add and srg_get_members commands worked without error. If they had given some hint about the group not existing I would have found the problem sooner
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'm trying to run PsN with run_on_sge but keep getting this error when I submit multiple runs simultaneously. I'm also getting "error: can't chdir to directory".
I suspect the PsN scripts may not be creating the run directories before submitting the job but am not certain. I'm also a little unsure of how to test this.
The nodes have access to the NFS mounted directories in question and the permissions look fine. Any pointers appreciated!!
Note to self: don't mess up the UID's when creating user accounts on the compute nodes.
UID's did not match between (3) compute nodes and the head node... which resulted in 'intermitted' failures with the error mentioned. Whenever a job was submitted to a UID mismatched node the job failed with what now seems to be a pretty obvious error message.
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
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.