Morning all.
Fresh Windows 11 install, fresh Windower install -- so everything is literally out of the box.
Windower files are set up on a separate internal NVME disc, and is not synced to OneDrive. So they're not on the OS volume and on a separate internal disc. Permissions are not an issue.
Any script I try to run through Windower immediately crashes the client to desktop. Even if it's just something like making a test .txt file for testing it crashes. (i.e. curr spark runs just fine through the console, but we if save that as a script file and try to run it it crashes the client).
Is there something in Windows 11 that needs to be disabled to restore this functionality? Was the //exec command deprecated/replaced with an addon for this?
Running Any Script Crashes Windower
Running any script crashes Windower
Does windower have uac access granted?
What's the file permissions to your windower directory look like?
Can you save exec scripts from the console??
What's the content of the test script?
What's the file permissions to your windower directory look like?
Can you save exec scripts from the console??
What's the content of the test script?
Fenrir.Jinxs said: »
Does windower have uac access granted?
What's the file permissions to your windower directory look like?
Can you save exec scripts from the console??
What's the content of the test script?
What's the file permissions to your windower directory look like?
Can you save exec scripts from the console??
What's the content of the test script?
1) Yes.
2) As mentioned it's on its own drive. Root of the drive, literally tested with giving permission to Everyone with full NTFS permissions. It's not permissions as stated above in the original post.
3) Yes.
4) As mentioned above, curr spark using the currencies addon. I've tested it with config FrameRateDivisor 0, input /t Charactername test, and a few other addons. The addon and the context of what the command is doesn't matter.
Turn on console log and look at console.log in windower directory after a crash.
Last few lines should give a clue.
`console_log 1` in windower console.
Do you have the file you are executing open elsewhere?
Are you aware windows uses exclusive file locks for writing which means no other program can open the file if you have it open for writing?
Not a betting man but the words "permission denied" might come up in the log.
Last few lines should give a clue.
`console_log 1` in windower console.
Do you have the file you are executing open elsewhere?
Are you aware windows uses exclusive file locks for writing which means no other program can open the file if you have it open for writing?
Not a betting man but the words "permission denied" might come up in the log.
Dodik said: »
Turn on console log and look at console.log in windower directory after a crash.
Last few lines should give a clue.
`console_log 1` in windower console.
Do you have the file you are executing open elsewhere?
Are you aware windows uses exclusive file locks for writing which means no other program can open the file if you have it open for writing?
Not a betting man but the words "permission denied" might come up in the log.
Last few lines should give a clue.
`console_log 1` in windower console.
Do you have the file you are executing open elsewhere?
Are you aware windows uses exclusive file locks for writing which means no other program can open the file if you have it open for writing?
Not a betting man but the words "permission denied" might come up in the log.
Didn't think about console logs, but the error it's spitting out doesn't make any sense from what's happening:
Code
[ 4.6.3.6 ] 2025-09-28 00:03:21.9983079 UTC --------------------------------------------------------------------- System.IO.IOException: The process cannot access the file 'D:\Mods\Windower4\scripts\autoload\autoload.txt' because it is being used by another process. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share) at System.IO.File.Open(String path, FileMode mode) at Launcher.Injector.Launch(String hook, Profile profile, Boolean debug, TimeSpan timeout) at Launcher.Tasks.LaunchTask.Run() at Launcher.Tasks.Task.Run(Core core) at Launcher.Core.Run() at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart()
Per console_log, last command ran was:
Code
16:26:01 > exec curr
The contents of curr.txt is the following:
Code
curr all spark; wait 2.5; curr all acco; wait 2.5; curr all impr; wait 2.5; curr all bead; wait 2.5;
No, it's not open anywhere else.
Yes, I'm aware of the file lock process.
Checking Event Viewer was a bust, as all it is showing is 0xc0000409 and that's just a generic quit unexpected catchall.
`System.IO.IOException: The process cannot access the file 'D:\Mods\Windower4\scripts\autoload\autoload.txt' because it is being used by another process.`
That is a permissions error. Opened elsewhere, exactly as I said. Since you do this for a living you probably don't need more help than that.
That is a permissions error. Opened elsewhere, exactly as I said. Since you do this for a living you probably don't need more help than that.
[+]
Pretty sure that auto load comes from starting a second windower session too fast, using the same profile
Is curr an alias for some addon?
Can you have the name of a script also be an alias?
Is curr an alias for some addon?
Can you have the name of a script also be an alias?
Dodik said: »
`System.IO.IOException: The process cannot access the file 'D:\Mods\Windower4\scripts\autoload\autoload.txt' because it is being used by another process.`
That is a permissions error. Opened elsewhere, exactly as I said. Since you do this for a living you probably don't need more help than that.
That is a permissions error. Opened elsewhere, exactly as I said. Since you do this for a living you probably don't need more help than that.
Except the file in question has zero to do with what the topic is about. I can confirm both the Windower autoload.txt isn't open in any files both in Task Manager and in Computer Management, and furthermore I'm not even trying to do anything WITH that file.
If it's a permissions issue with an open file, that isn't open at all in the system, and I'm not even running a command for that file in particular, how does that factor in?
Furthermore, this is a fresh Windows 11 installation (USB drive, wiped and deleted all previous partitions), and a fresh Windower installation and setup.
If it's doing this outside of the box when Windower's basically a click > next > done install, then how is it a permissions issue with an open file?
If it does this after a fresh reboot, launching Windower and it does this immediately upon first launch, then how is it a permissions issue with an open file? Is the latest deployment of Windower so *** up NO ONE can run scripts? I highly doubt it otherwise it'd be a widespread issue.
If you're going to try to help, than actually do so. Otherwise *** off because all your response seems like is a kid jumping up "OH BUT IT SAYS HERE IT'S THIS SO YOU'RE WRONG" is pathetic.
I may do this for a living, but that doesn't mean I'm a *** deity. I put that there before when I know there's nothing open, or that it's not NTFS permission, I mean I've already checked for that as I would with a client.
I'm asking for anything to check outside of the obvious as I've already checked those. I purposely went through this on a second machine as I noticed this on my Windows 10 box and I couldn't figure it out there. I figured since it was a 5 year installation on the machine it might have been something in the user profile NTUSER.dat file, and as I was setting up the new machine I figured I'd test it there as well.
Fenrir.Jinxs said: »
Pretty sure that auto load comes from starting a second windower session too fast, using the same profile
Is curr an alias for some addon?
Can you have the name of a script also be an alias?
Is curr an alias for some addon?
Can you have the name of a script also be an alias?
Curr question was answered above. It's called Currencies. Curr is the shorthand version. But I've tested the file labelling is *** currcheck, curr1, curr2, curr3, etc. It doesn't matter what the name of the file is called. I've ran one called test.txt that's literally just showfps for Windower -- it crashes the client.
I boot up the machine. I load Windower and log in. I wait 1 minute, 5 minutes, 10 minutes -- irrelevant on time.
This is a new Windows 11 install, a new FFXI install, a new Windower install. This is running one single Windower instance. Running any script immediately hard crashes the client.
Ya gotta slow down buddy
Sometimes in life ya have to do the little dumb things before you do all the over the top extras
What if you run exec with no arguments
Sometimes in life ya have to do the little dumb things before you do all the over the top extras
What if you run exec with no arguments
Do you have antivirus?
When you say windower files are on a separate drive, are there any symlinks?
When you say windower files are on a separate drive, are there any symlinks?
This entire thread could have been avoided if you had come to the place where the people who actually know how windower actually works are - the windower discord.
Do that, we'll help you troubleshoot this. Link is on the windower website.
Do that, we'll help you troubleshoot this. Link is on the windower website.
Yes, of course help the person. They have such a lovely way with words and "ask" for help in a very non-entitled and non-patronising way, of course.
Not like they do this for a living and already have all the information they need or anything.
Not like they do this for a living and already have all the information they need or anything.
[+]
Okay you got me curious. What's up with the "they do this for a living" stuff? I didn't see them say that in this thread
Dodik said: »
Are you aware windows uses exclusive file locks for writing which means no other program can open the file if you have it open for writing?
That is up for the software that is not something windows does all the time.
I have plenty of my scripts or even add-ons settings file open for writing and the add-on writes to them fine
DaneBlood said: »
Dodik said: »
Are you aware windows uses exclusive file locks for writing which means no other program can open the file if you have it open for writing?
That is up for the software that is not something windows does all the time.
I have plenty of my scripts or even add-ons settings file open for writing and the add-on writes to them fine
That's because windower cheats. The lua files library simply opens and closes the actual OS file handler immediately around each operation, exactly to avoid situations of lock conflict due to the dev not writing code properly. If you open the file handler manually and leave it open, the file will be locked and other processes (including other addons) will fail to access it, because as said windows does lock the file exclusively to a single process while writing.
[+]
What Lili said.
More poor understanding of basic OS concepts. #notsorry
More poor understanding of basic OS concepts. #notsorry
All FFXI content and images © 2002-2025 SQUARE ENIX CO., LTD. FINAL
FANTASY is a registered trademark of Square Enix Co., Ltd.