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.
Related
I am running Octave 4.4.1 on MacOs Catalina 10.15.7. For some weeks I have been having this message poping up when a code is running: "
It seems that [name of script] has been modified by another application. DO you want to reload it?
I click Yes each time it pops up, but when the code is running, it just keeps coming back, and sometimes Octave becomes unresponsive although the script has finished running
All I could find on the internet were either some old posts with answers about outdated Octave versions, or very complicated stuff that I would not be able to implement.
Any one knows why this happens, and what to do about it?
thanks a lot
This message is exclusive to the GUI version of Octave, and it comes up if you have a file open for editing in the Octave GUI Editor window, and the file's contents change due to a process unrelated to the Octave Editor.
E.g. you may also be editing the file on an external text editor at the same time? Or your script may be copying / generating a new file under the same name as a file that you've got open in the editor, effectively overwriting the now-out-of-date version that's still being displayed in the Octave Editor?
Octave gives you this warning to prevent you from 'saving' in your editor, and therefore undoing any changes that had been made by the external process in the meantime.
I can see my page get crash(see aw, snap page) with 20% proprobility after 10 mins(otherwise it runs well like forever)
so I tried:
1) CPU and memory check with task manager, and see no increasing(so no leakage).
2) enable crush log in the chrome://settings/
result:
2.1) see still nothing in the chrome://crashes page, not even a crush ID (0 crashes).
2.2) see nothing in the folder under path
C:/%User%/AppData/Local/Google/CrashReports (nothing in) nor
C:/%User%/AppData/Local/Google/Chrome/User Data/Crash Reports (folder not exist)
2.3) but indeed see DMP in the:
C:/%User%/AppData/Local/Google/Chrome/User Data/CrashPads/reports
but seems they are not readable, and it also seems not the correct address for crash logs
3) can get chrome log either by command line arguments, or using sawbuck, but found nothing but only 2 errors, one for sawbuck itself, and another saying can't send the report to google.
So the questions are:
1) are those DMP the crash logs(the default Dir for dump file has been changed for chrome v50)
2) how can I abstract information out of the DMP file, if chrome://crashes page shows nothing (for chrome on windows)
p.s. 2 usage pages are found at https://www.chromium.org/developers/decoding-crash-dumps
https://www.chromium.org/developers/crash-reports
but seems it's not for windows without a recompile of chrome's component, is there any 3rd party tools to interpret the DMP file?
env informations:
chrome version: 50.0.2661.02 m
; Host OS: windows 10
The crash dumps (.dmp files) in C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Crashpad\reports can be read by standard Windows debuggers. WinDbg is one tool (provided by Microsoft) for analysing these dumps; it's not going to win any beauty contents, but it's powerful and gets the job done. The recommended way to obtain it is, somewhat bizarrely, the Windows Driver Kit.
You'll need debugging symbols to make sense of the results, and these aren't included in standard builds of Chrome. To get symbols for both Chrome and the Windows runtime, set the following as your Symbols path:
SRV*c:\symbols*https://msdl.microsoft.com/download/symbols;SRV*c:\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com
There are numerous resources on using WinDbg on the web; this cheat sheet contains some useful commands to get you started.
Recently I’ve release my Windows 10 UWP application in store .
Last week I released a new update in store ,after a week I receive lots of mail from users about a bug in my app.(Pages that want to connect to database can't open and they crash)
Funny part is that when I deploy and run it by visual studio or Powershell (appx-package command) everything works fine, so I can't find a thing.(Even in RemoteMachine and Emulator)
So I was checking my dashboard in dev center and find some "failed log" there.
How can I use these logs to find my problem?
I'm really stuck and don't know what to do!!
Solution:
In Properties of the Project there is a file named Default.rd.xml that contains an element like <Assembly Name="*Application" ...
So by mistake the attribute it was changed to name="*Application" (Don't know what changed that and VisualStudio didn't notice that.)
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
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.