I'm running Windows Server 2008 with a Blackmagic Decklink card. Everything works fine with the GUI but when I try to start from command line it exits with an unknown error.
Any ideas?
Note: I have the desktop experience enabled.
Looks like a frequent problem that effects many FMLE users. Common suggestions include:
use the absolute latest version of FMLE
update DirectX
update all video and audio-related drivers
remove/rename startup.xml from "[volume]/Users/[user name]/AppData/Roaming/Adobe/Flash Media Live Encoder [version]/" so the program can get clean settings
There is also a small chance that tweaks to common security measures may help, such as disabling Data Execution Protection for all but essential OS files or exclude program directories in your anti-virus software (only if essential, of course!)
I found out what the problem was, apparently if the fmesessions.dat (C:\ProgramData\Adobe\Flash Media Live Encoder 3.2) gets large enough FMLEcmd.exe fails.
Related
I make sure all of processes of VS Code have exited, but I can’t delete the bin directory.
I tried many tools to find which process is using the directory, but none of them reported.
The problem occurs on all of my Windows devices and I need to manually update each time.
This link suggests a workaround might be to stop Skype for Business:
https://github.com/Microsoft/vscode/issues/60697
Notes:
Different users had to close Skype for Business, SkypeBridge, or even f.lux (?)
Per the link, you can use Windows Process Explorer to determine which apps are holding "bin" open
In my case it was Teams, and found that by searching for Skype in Windows Process Explorer. Killed it and the update went smoothly.
I've taken a GPUView trace on one machine running Windows 10 but want to analyze the trace on a different machine running Windows 7. When I try to open the trace file, merged.etl, using GPUView I see the message:
This etl file has data that was captured on a version of the OS that is different from the current OS. The data may not be displayed correctly or expose other side effects in GPUView.
Would you like to continue loading this file anyway?
If I choose to open the trace anyway GPUView opens but there is nothing to view.
I know I should be able to view traces this way but I don't know the magic sauce to make it work. Does anyone know it?
As a last ditch effort, after finding nothing for this error online, I tried pointing GPUView to a folder containing symbols from the OS the trace was captured but this doesn't have any effect.
Thank you,
Lawrence F.
I discovered this was happening due to using different GPUView versions on the two machines in question. I thought I had used the same version but it turns out I had serveral. I removed all the old version and installed the Windows 10 SDK on each machine (includes GPUView). This allowed me to view the trace on the Windows 7 host
Recently forced upgraded to windows 10 by microsoft. Windows Start and cortana froze. Searched google and from powershell ran
Get-AppXPackage -AllUsers | Foreach
{Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
Now lot of my windows application have disappeared. They show up with #{AppPackageName} in taskmanager or when searched using cortana for example #{Microsoft.ZuneMusic_2019.6.15131.0_neutral_~_8wekyb3d8bbwe}. I can not remove these app using any command like
Tried to install store app manually and get error Merge Failure : error 0x80070003 : Cannot register the Microsoft.WindowsStore_2015.21.25.0_x64__8wekyb3d8bbwe package because there was a merge failure with the following file: C:\Program Files\WindowsApps\Microsoft.WindowsStore_2015.21.25.0_neutral_split.scale-100_8wekyb3d8bbwe\resources.pri
Full log below:
Now I understand that store app is not getting add because add process is causing error or merge failure with another package (?). The problem is get/Add-AppxPackage are resolving dependency of application with package-version: Microsoft.WindowsCalculator_10.1510.13020.0_neutral_split.scale-100_8wekyb3d8bbwe
AND/OR
Microsoft.WindowsCalculator_10.1510.13020.0_neutral_split.language-hi_8wekyb3d8bbwe
My laptop c:\program files\windowsapp only has Microsoft.WindowsCalculator_10.1510.9020.0_neutral_split.scale-100_8wekyb3d8bbwe (not diff in version 13020 and 9020). Note: The version no on app is 13020 but dependent package on drive is 9020.
Second package is missing from drive (Microsoft.WindowsCalculator_10.1510.13020.0_neutral_split.language-hi_8wekyb3d8bbwe).
How to get my calculator and windows store application back.
<1>Create a new user account and Log into the new account
<2>You can also try
Running the System File Checker by running
sfc /scannow
Download files from Windows Update to replace the corrupt ones by running
DISM /Online /Cleanup-Image /RestoreHealth
You may try the following, at your own risk.
I had the same issue after trying to reinstall the apps via that powershell thingy. Fixed it and returned the apps to their out-of-box state by first wiping everything from C:\Program Files\WindowsApps and C:\Users*\AppData\Local\Packages and then reinstalling Windows over itself from the tech bench ISO (from under Windows and keeping "traditional" apps and files in place, of course). I had to use the ISO because the media creation tool wasn't cooperative at all, throwing some error at me. Just in case, the aforesaid wiping didn't cripple the vitals like the immersive control panel or something else, just the typical no start menu/dead modern apps/no right click on the taskbar items.
By the way, the whole problem started after the 1511 update. Modern apps would refuse to remember their settings, and windows shell experience host would freeze for no reason, taking the start menu and things like volume control with it. I've had this Windows installation for a couple of years now, and the system has gone pretty smoothly through the 8.0-8.1-10 update process over that time, but that 1511 screwed something big time.
At present I cannot run it (SQL Developer 4.1) because it hangs on "Restoring Editors" while starting. I suppose I've done it by exiting it before by killing sql developer process because it was hanged on fetching objects to Schema Browser so long...
Maybe I would clean some temporary files but can't find any.
Any ideas?
Deleting files from c:\Users\MY_USER\AppData\Roaming\SQL Developer\SQL History
and c:\Users\MY_USER\AppData\Roaming\SQL Developer\System...
Really helped me to resolve the connection issues
Basing on this thread https://community.oracle.com/thread/2564842 I've created own solution.
Extract installation of current version SQL Developer (4.1.0.17.29)
At "c:\Users\MY_USER\AppData\Roaming\SQL Developer\"
I've changed directory name system4.1.0.17.29 to system4.1.0.17.28.
After running newly extracted SQL Developer (4.1.0.17.29) I was prompted to let copy configuration from version 4.1.0.17.28 to 4.1.0.17.29 ;)
Everything works great now. I suppose that running the same (broken) installation after decreasing version could also help.
Remove folders c:\Users\USERNAME\AppData\Roaming\SQL Developer\system4.1.3.20.78\system_cache*. SQLDeveloper will recreate it after launching.
Just execute sqldeveloper as administrator. It works fine!
In my case the problem was because of windows compatibility issue. So I've selected my windows version and it's stop from randomly crash after startup
Our setup:
Windows 10
Sqldeveloper Versions <= 20.4.0
We observed this problem as well. Even worse while working over a VPN connection. I followed a couple of hints with more or less no effect.
To move
C:\Users\<USER>\AppData\Roaming\SQL Developer
to a local directory by adding this line
AddVMOption -Dide.user.dir=c:\temp\sqldev-conf
in the \sqldeveloper\bin\sqldeveloper.conf file gave us some improvement, but the “IndexPreferencesTask” still got stuck several times on startup.
After some more hours on unsuccessful research, we moved back from JDK 11 to JDK 8.
This solved 99% of the problem. The “IndexPreferencesTask” still hangs on startup but for less than a second.
Sounds to me like a problem with JDK 11.
In my case when i changed Tools --> Preferences --> Environment -> Look and Feel to Windows it is solved.
Delete the History files from C:\Users\User\AppData\Roaming\sqldeveloper
Restart the PC
In my case, the solution was kind of weird. After battling to resolve this for 2 days, no luck. Suddenly, on my mac, I searched for sql developer, not sqldeveloper. It popped up a sqldeveloper application (not sure how that is different from what I have been trying to open ), clicked it and boom, it opened. My guess is that there is a copy of that app on my system that I should have been opening rather than trying to open the reinstalled app. Note: I reinstalled the app after it started misbehaving though.
Operating System: Windows 10
Oracle Sqldeveloper Ver: 17.4.0
The problem has been noticed sometime when any network security
patch was installed on your machine. Looks like the patch impacts
your cached data under your user profile folder.
As above Lakh, rtbf and others answered. Removing below folders
will resolve the issue.
C:\Users\<userId>\AppData\Roaming\SQL Developer\SqlHistory
C:\Users\<userId>\AppData\Roaming\SQL Developer\system17.4.0.355.2349
If any one find more approriate reason please feel free to
disagree with my answer.
After setting up WinQual and WER for the first time, I intentionally inserted a crash in a release build expecting\hoping to get the WER dialogue but instead still get the dialogue containing "runtime error! The application has requested the runtime to terminate in an unusual way...".
Everything seems to be working correctly regarding the setup of WinQual (along with all the supporting symbol server, source server,WinQual account, submitted mapping files and verified their presence my WinQual account). Now I want to verify that dump files are created, submitted to WinQual and I can retrieve them for debugging.
I verified that my PC's (XP Pro SP3) error reporting is enabled (system properties-error reporting). I figured the hard part would be setting up everything above not getting the program to actually show the WER dialogue. Is there some modification to the exe or the PC needed?
It's good to know I may not be (completely) crazy. You're right that external issues were causing problems for the WER dialogue.
I changed the crash to the code above, just in case my version was too brutal, and ran the application on three machines and it appears that the presence of Visual Studio and/or just-in-time debugging, on XP and Win7, was affecting the WER dialogue. For anyone interested this is what I saw:
XP with Visual Studio. Asked to choose a debugger and if I chose No, the program exited without the WER dialogue.
XP without Visual Studio. Displayed WER dialogue and sent the error report (yeah).
Win7 with Visual Studio. Did not crash at all.
Win7 without Visual Studio. I have not tested yet but suspect it will behave correctly.
So as you implied, a combination of the crashing code and unrepresentative testing environment were thwarting my test.
Thanks so much!
If you are using a WinForms application there is a catch handler in it's event loop that pops up a dialog and prevents Windows Error Reporting (WER) from kicking in.
This call prevents this from happening.
(http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/176b7f8c-3efb-4e6f-8deb-c685c62629db/)
The magic line to fix:
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
There shouldn't be anything you need to do in the application to get it working. I suspect you've somehow managed to crash in some strange way that is not working too well with WER. Try adding a crash once the application has initialised, rather than during application startup (if that is what you're doing). I usually do something like this:
int* p=0;
*p=1;
Another possibility is that your machine isn't going to give you the same results as an end user because of the Just In Time debugger of Visual Studio, so try it on a typical end-user machine. A further possibility is that your machine is XP and WER support was at an early stage in XP and is better in Vista and Win7, so try crashing the app on a newer machine.