I have a simple bat file which does the following:
#echo off
mkdir folder1
mkdir folder2
echo.>file1
move file1 folder1\file1
When I run this on Windows 8 it will often hang the shell and explorer.
Interestingly, turning on/off the echo does seem to effect the chance of running into the bug (echo off hits the bug more often it seems) but I can get the bug either way. Suggests a race condition of some kind.
Anyone have an idea why this hangs on Windows 8? It doesn't on Windows 7.
I've also tried this using powershell. It happens less often (had to do it about a hunderd times before I hit the problem) but still occurs.
Turns out the problem was a combo of antivirus and search indexer. Both touch all the files in the FS as soon as they're created. I also suspect that the test machine being a VM has something to do with it (it is likely a little underpowered).
tldr; turning off windows.search from services fixed things.
Related
Before reporting to Microsoft I want to ask here. I have a problem that I cannot see Live Visual Tree of my WinUI 3 application. I cannot even see the in-app toolbar. I can see both in WPF and UWP application, no problems. I have these options for hot reload, that should be fine.
I am using VS2022 17.3.1 and Windows App SDK in version 1.1.4. Weird is that it was functioning without problems, but one restart of application just broke that. I also tried adding the ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO to environment variables manually, but no luck there.
It seems that 32-bit WinUI 3 app is working fine, it only affects 64-bit WinUI 3 applications. Even the new and blank ones. Packaged/unpacked type doesn't affect the problem.
I tried uninstall and install VS again, no changes.
So I did finally find a solution (more of a workaround) to this.
Run following commands in elevated cmd, where you replace WindowsAppRuntime version with version you currently have (for me it is Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe):
takeown /f "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe" /r /d y
icacls.exe "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe" /grant Users:(RD,R,REA,RX) /t
Don't know what it does, but it is working. This solution is taken over from Developer Community
UPDATE:
You have to repeat this procedure when you update Windows App SDK to a new version.
Here is a PowerShell command that loops over all WindowsAppRuntime folders and applies the fixes on #benderto's answer.
Get-ChildItem -Path 'C:\Program Files\WindowsApps\' -Filter 'Microsoft.WindowsAppRuntime*' | Foreach {
takeown /f "C:\Program Files\WindowsApps\$_" /r /d y
icacls.exe "C:\Program Files\WindowsApps\$_" /grant "Users:(RD,R,REA,RX)" /t
}
You don't need to restart Visual Studio for this to take effect. Restarting the debugging session is enough.
After lots of reinstallion, 100+?, I came across with this information then problem solved.
It is very frustrating the recent quality of Visual Studio 2022 after 17.2. Each update gets me reinstall loops again, again and again, just because something broken.
This time, MAUI (WinUI 3) XAML Hot Reload won't work.
XAML Hot Reload
So I created 3 VMs and installed with different detail of workloads, and tried to figure out "What's wrong". But I failed.
The error seems random. However, I did get some thing strange.
The Hot Reload was "working" after installaion and I left the VM on. After awhile back, I stopped debugging and restarted to debug, the working one became "not working" somehow over time, so I compared two snapshot, one work, one did not. After comparing installion configuration, run with user, run with admin, MAUI App with .net 6.0, MAUI App with template 7.0, both registry, both disk contain (entire C:). I found nothing, all identical as they should be.
Checking Logs:
Event Log, AppData\Local\Temp\VSLogs, AppData\Local\Xamarin\Logs\17.0, the Output of VS
However, the Output: debug. Did make me tracing the component binding process, also found nothing.
The One "Not Wotking":
The One "Not Wotking"
The One "Working":
The One "Working"
Huge data but no luck:
Assembly binding log
Windows Policy, no luck: Audit Access Deny
I have to say the error logs are well hidden.
After lots of google thing, I came across with this information then problem solved. It is a Permission problem.
And then I dig a little further, here i found:
VS Output:
WindowsAppRuntime, installed at first run, may be update after
C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1005.616.1651.0_x64__8wekyb3d8bbwe
The list of files that Permissions are different (Not Working vs. Working):
CoreMessagingXP.dll
dcompi.dll
dwmcorei.dll
DwmSceneI.dll
DWriteCore.dll
marshal.dll
Microsoft.DirectManipulation.dll
Microsoft.Foundation.winmd
Microsoft.Graphics.winmd
Microsoft.InputStateManager.dll
Microsoft.Internal.FrameworkUdk.dll
Microsoft.UI.Composition.OSSupport.dll
Microsoft.UI.Input.dll
Microsoft.UI.Windowing.Core.dll
Microsoft.UI.winmd
Microsoft.Web.WebView2.Core.dll
Microsoft.Web.WebView2.Core.winmd
resources.pri
WindowsAppRuntime.png
WindowsAppSdk.AppxDeploymentExtensions.Desktop.dll
wuceffectsi.dll
en-GB\Microsoft.ui.xaml.dll.mui
en-GB\Microsoft.UI.Xaml.Phone.dll.mui
Microsoft.UI.Xaml\Assets\NoiseAsset_256x256_PNG.png
Conclution:
The "Microsoft.WindowsAppRuntime" will get installed on first run and will not get uninstalled with Visual Studio uninstallation.
The "Microsoft.WindowsAppRuntime" may get updated and permission also get changed.
The ACL permission of Microsoft.WindowsAppRuntime folder and files in it may change somehow after some time, same version (Did not go this far to see why).
Manipulate the Permission manually does the trick
Simple Rest (SYSTEM access right is required, PsExec):
psexec64 -i -s cmd.exe /k icacls.exe "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1005.616.1651.0_x64__8wekyb3d8bbwe\*.*" /reset /t
Minimun Reset (for my case, as soon as this reset done, the hot reload shows up when debug, remember to restart debug):
psexec64 -i -s cmd.exe /k icacls.exe "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1005.616.1651.0_x64__8wekyb3d8bbwe\Microsoft.Internal.FrameworkUdk.dll" /reset
I have designed a GUI that I want to run as soon as I turn on my Raspberry Pi. It is currently set up to automatically log in as user on startup, but if that makes the process more difficult I can change that. My Raspi runs on Raspbian 10 (buster), which has made things difficult since I can only find tutorials for Raspbian 8 or so.
I have tried modifying autostart folder, but it is not in the same location as it was in previous Raspbian versions and doesn't seem to be working the way it used to. Tutorials have said to create a .desktop file in /home/pi/.config/autostart but I don't have a .config folder, or at least it's hidden. For me, autostart is in /etc/xdg/autostart and when I try to create a new file here using nano in the terminal, I get the message [Directory '/etc/xdg/autostart' is not writable] and it doesn't save my file.
I have also tried calling my script in /etc/rc.local but it did nothing. Some have said it doesn't work for GUIs.
Here's what I type into terminal:
$ nano /etc/xdg/autostart/gui.desktop
and a new file pops up, but at the bottom I get the warning [Directory '/etc/xdg/autostart' is not writable]
How can I get my GUI script to run on startup with Raspbian 10 (buster)?
There are a number of issues here, first when you are looking at tutorials recognize that Linux distros are built in layers, for simplicity let's say your "layer stack" looks like this: kernel, systemd, x11, xdg, lxde. The kernel boots, then starts systemd, which then starts x11 (and a lot of other stuff), x11 starts xdg (and some other stuff, I think), lxde is started by either x11 or xdg I'm not sure which.
You want to add something to this process, you can do it at the kernel level (bad idea), at they systemd level (probably not right unless its a daemon), at the x11 level (still probably bad as you still don't have a user session yet), or at the xdg or lxde level.
xdg is probably the right place as it has all you need ( a gui, a user session) while being common (xdg will still work if you switch window managers, probably)
With that out of the way, why isn't your solution of modifying xdg working? It's because '/etc/xdg/autostart' is a system configuration directory. Any changes made to it will apply to all users. You may want this, but the system is trying to protect other users on your system and only allows root to make changes to everyone. If you want to do that use "sudo" (documented elsewhere on stack exchange and the internet). If you want to do it just for you use ~/.config/autostart, (https://wiki.archlinux.org/index.php/XDG_Autostart) you might need to create that directory with "mkdir ~/.config/" and then "emacs ~/.config/autostart"
Would it be better to have the python program run in a terminal window from startup? That way you would see what it is doing in case of errors.
If so, perhaps check this out https://stackoverflow.com/a/61730679/7575617
By the way, in the file manager, hit CTRL+H to toggle viewing hidden files and folders.
I'm using freepascal. So after I run my code compiler creates an exe file that should create few text files. However after it creates an exe file it says "Program c:\fpc\2.6.4\bin\i386-win32\maxmin.exe exited with exitcode = 2". No text files are created. If I later run maxmin.exe manually - it works fine.
UAC - disabled and EnableLUA = 0. But I still pretty sure - it is windows 8.1 rights issue problem.
Some possibilities, in descending order of likeliness:
Note that exitcode 2 usually indicates a file not found error.
Working directory. While manually executing you set the working directory by CDing with the shell, and when indirectly executing the program's assumptions about a working directory are not satisfied.
Sometimes locks linger on Windows for a short while. Usually not noticeable in the manual execution time frames, but when programmatically executing programs in quick succession it might happen.
If you have the feeling that the EXE doesn't run at all, it might be an security software issue. After the binary is generated, the antivirus kicks in and wants to scan, locking the binary for a few seconds.
I'm writing app like System Activity in Mac. I used modified darwin.h and darwin.c from this topic.
But it seems that it shows correct info only for certain fields (and some time ago it showed all correct info but only for current process - this app), for everything else it shows correct only pid, process name, group/owner. Everything else like cpu/mem/disk usage is nulled. I think it may be something with sandbox or security. Tried to move application to /Applications and setting root/wheel 755 but it's not work, still zeroed values.
Here's my output : click
Code changed in darwin.c : click, written after a lot of commented printf lines
Also there is a free apps approved in AppStore like SystemInfo (com.lymbilesoft.systeminfoliteforiphone) that shows detailed info about disk and processes, so how do it work? Tried nm-ing it's binary but did not find something useful.
Can someone please help me with it?
I'm not sure if this is the only problem, but it certainly is possible that your app needs to run as root for this to work correctly.
However, simply installing the app in /Applications, doing chown root.wheel, and chmod 755 will not cause it to run as root. It will still run as user mobile.
In order to get the app to run as root, see this answer
I've used this technique successfully, and if you have a jailbroken phone, you can navigate to /Applications/Cydia.app and see that this launch script is how Cydia does this, too.
I use ps aux from the Terminal/Command Line. That gives me all the stuff I need, regarding your concerns.
I'm an android developer. I acquired recently a Samsung Galaxy S3 (I9300) and I am having some problems with it.
The error management doesn't work. I mean, when an app crashes, it doesn't show "Force close", the phone just freezes.
I had an HTC before; I use it when I'm developing too, and with the same malfunctioning app, my HTC shows me force close, but the S3 freezes and I have to restart it.
As you can imagine, this is very annoying.
I found a temporary solution, but it affects wifi. Using this app
https://play.google.com/store/apps/details?id=com.issess.fastforceclose&feature=search_result#?t=W251bGwsMSwyLDEsImNvbS5pc3Nlc3MuZmFzdGZvcmNlY2xvc2UiXQ..
and enabling "old fast force close" seems to solve the problem, but it has wifi related problems.
Things I have tried
Clean ROM, wiping data and Dalvik cache (it works at the beginning, but suddenly the phone freezes and when I restart, the error management doesn't work any more)
Delete all apps
What am I missing? How can I resolve this?
see http://forum.xda-developers.com/showthread.php?t=1843837 , especially post #8
quoting:
I finally figured out what "Fast Force Close" app is doing to stop the freeze. It does something rather simple: it basically "hides" the /data/log folder, by moving it aside, and replacing it by a symlink. And this then also, causes Wifi to not connect after a reboot (dunno why)
mv /data/log /data/log_backup
ln -s /dev/null /data/log
To "disable" the fix, it just does the reverse.
Anyway, this got me thinking that the solution was somehow related to stuff happening in that folder. And one of the things happening in that folder, on a Force Close, is that it receives the output of the dumpstate command:
dumpstate -k -t -n -z -d -o /data/log/dumpstate_app_error
So, my solution for the "Freeze instead of Force Close dialog" issue is to put some files in the /data/log folder, with such permissions that dumpstate can not do its thing.
I found this to solve the issue, but I don't know if there are side effects.
If you want to implement this, you can do it in many ways (e.g. even through terminal emulator or probably some root file explorer). I'm attaching a flashable zip that will do this for you. (see XDA link)
Apart from some boilerplate code, the essential bit is this (in updater-script in the zip):
ui_print("Apply fix...");
delete("/data/log/dumpstate_app_error");
delete("/data/log/dumpstate_app_error.txt.gz");
delete("/data/log/dumpstate_app_error.txt.gz.tmp");
package_extract_file("placeholder", "/data/log/dumpstate_app_error");
package_extract_file("placeholder", "/data/log/dumpstate_app_error.txt.gz");
package_extract_file("placeholder", "/data/log/dumpstate_app_error.txt.gz.tmp");
set_perm(0, 0, 0400, "/data/log/dumpstate_app_error");
set_perm(0, 0, 0400, "/data/log/dumpstate_app_error.txt.gz");
set_perm(0, 0, 0400, "/data/log/dumpstate_app_error.txt.gz.tmp");
The issue was resolved for me by updating the phone to the latest available android version.