I got the updated release files today. The updated Ashita.dll downloads but the launcher sits at 100% and then silently exits. Subsequent executions have it simply timing out after checking for updates. Looks like an unhandled exception.
Doesn't seem to be affecting my wife's PC, just mine.
Application: Ashita.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.IOException
at System.IO.__Error.WinIOError(Int32, System.String)
at System.IO.FileStream.Init(System.String, System.IO.FileMode, System.IO.FileAccess, Int32, Boolean, System.IO.FileShare, Int32, System.IO.FileOptions, SECURITY_ATTRIBUTES, System.String, Boolean, Boolean, Boolean)
at System.IO.FileStream..ctor(System.String, System.IO.FileMode, System.IO.FileAccess, System.IO.FileShare)
at System.IO.File.Open(System.String, System.IO.FileMode, System.IO.FileAccess)
at Ashita.Model.DownloadTask.DoTask()
at Ashita.ViewModel.MainWindowViewModel+d__12.MoveNext()
at System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.b__6_1(System.Object)
at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
I got the updated release files today. The updated Ashita.dll downloads but the launcher sits at 100% and then silently exits. Subsequent executions have it simply timing out after checking for updates. Looks like an unhandled exception.
Doesn't seem to be affecting my wife's PC, just mine.
Application: Ashita.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.IOException
at System.IO.__Error.WinIOError(Int32, System.String)
at System.IO.FileStream.Init(System.String, System.IO.FileMode, System.IO.FileAccess, Int32, Boolean, System.IO.FileShare, Int32, System.IO.FileOptions, SECURITY_ATTRIBUTES, System.String, Boolean, Boolean, Boolean)
at System.IO.FileStream..ctor(System.String, System.IO.FileMode, System.IO.FileAccess, System.IO.FileShare)
at System.IO.File.Open(System.String, System.IO.FileMode, System.IO.FileAccess)
at Ashita.Model.DownloadTask.DoTask()
at Ashita.ViewModel.MainWindowViewModel+<ProcessUpdatesThread>d__12.MoveNext()
at System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.<ThrowAsync>b__6_1(System.Object)
at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
Faulting application name: Ashita.exe, version: 3.1.0.3, time stamp: 0x5b5d3a76
Faulting module name: KERNELBASE.dll, version: 10.0.18975.1000, time stamp: 0xd42c49c4
Exception code: 0xe0434352
Fault offset: 0x0011db62
Faulting process id: 0x31e0
Faulting application start time: 0x01d566bcf309c37a
Faulting application path: D:\Program Files (x86)\Ashita\Ashita.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report Id: f830b574-2933-447d-8e30-a2a81cce8e65
Faulting package full name:
Faulting package-relative application ID:
Ensure that you have full permissions to the location Ashita is installed to.
Ensure that your anti-virus is not trying to delete Ashita.dll. (Best to just whitelist the whole Ashita folder.)
Ensure that Windows Defender isn't trying to delete things.
Generally the only reason it'll sit at 100% and die out would be not having proper write permissions or an anti-virus trying to remove the file or taking forever 'scanning' it.
Make sure of the following:
- Close all instances of Ashita before updating.
- Ensure that you have full permissions to the location Ashita is installed to.
- Ensure that your anti-virus is not trying to delete Ashita.dll. (Best to just whitelist the whole Ashita folder.)
- Ensure that Windows Defender isn't trying to delete things.
Generally the only reason it'll sit at 100% and die out would be not having proper write permissions or an anti-virus trying to remove the file or taking forever 'scanning' it.
Ashita's been running perfectly fine until the last update to Ashita.dll. I downloaded the last build from 2 months ago and set --noupdate, and it runs normally again.
It might be relevant that I run Ashita from D:, and when I copy it to %ProgramFiles(x86)% on C:, it does launch.
1. Yeah, I only run once instance.
2. Yep. No changes here.
3. I only have Defender.
4. Nope.
Ashita's been running perfectly fine until the last update to Ashita.dll. I downloaded the last build from 2 months ago and set --noupdate, and it runs normally again.
It might be relevant that I run Ashita from D:, and when I copy it to %ProgramFiles(x86)% on C:, it does launch.
The last update we pushed was to fix a bug with the resource parser. That won't have any affect on Ashita updating properly in the launcher. Generally, issues like this are due to something on your system preventing the dll from being deleted and replaced. The download can be directly accessed via: https://git.ashitaxi.com/Ashita/Ashitav3-Release/raw/branch/master/Ashita.dll
You can test and see if there are issues with the direct link too for you. At this time, no one has reported any issues and all the machines and VMs I've tested on have no issues getting the update, so this leads me to believe the issue is on your end.
If you don't mind telling me, what's the full path to where you have Ashita.exe installed at? I'll try and recreate the same environment as you to see if there are issues with the path.
We do recommend that Ashita be installed to the root path of a drive, generally C:\Ashita\ when possible. However, it should work from D:\Ashita\ and so on as well as long as you have proper permissions to the drive.
The last update we pushed was to fix a bug with the resource parser. That won't have any affect on Ashita updating properly in the launcher. Generally, issues like this are due to something on your system preventing the dll from being deleted and replaced. The download can be directly accessed via:
https://git.ashitaxi.com/Ashita/Ashitav3-Release/raw/branch/master/Ashita.dll
You can test and see if there are issues with the direct link too for you. At this time, no one has reported any issues and all the machines and VMs I've tested on have no issues getting the update, so this leads me to believe the issue is on your end.
If you don't mind telling me, what's the full path to where you have Ashita.exe installed at? I'll try and recreate the same environment as you to see if there are issues with the path.
We do recommend that Ashita be installed to the root path of a drive, generally C:\Ashita\ when possible. However, it should work from D:\Ashita\ and so on as well as long as you have proper permissions to the drive.
Also if possible, could you open the 'Event Viewer' on your system and try to locate the crash information inside of that and paste that here too? That should include a bit more details on the crash outside of the main exception code. '0xe0434352' just means 'unhandled exception' so the sub-codes that will be in the event viewer may hold some better information.
Also if possible, could you open the 'Event Viewer' on your system and try to locate the crash information inside of that and paste that here too? That should include a bit more details on the crash outside of the main exception code. '0xe0434352' just means 'unhandled exception' so the sub-codes that will be in the event viewer may hold some better information.
I'll give it a try tonight, but it looked like the updated DLL was replaced fine. I didn't compare checksums but I could do that.
The path I'm using is D:\Program Files (x86)\Ashita\ . I can't confirm offhand but I believe I have it installed to the same path on my wife's PC and she hasn't had any issues either. I wouldn't expect it to be relevant either.
Also hopefully not relevant but I'm on Insider at home. I believe it's build 18970.
Is there any chance that you're using Debug.Write? I could always run DebugView and see if anything is being written. I mean I know it's an unhandled exception so it's not like there would be any specific debugging info written, but just throwing it out there.
I'll give it a try tonight, but it looked like the updated DLL was replaced fine. I didn't compare checksums but I could do that.
The path I'm using is D:\Program Files (x86)\Ashita\ . I can't *confirm* offhand but I believe I have it installed to the same path on my wife's PC and she hasn't had any issues either. I wouldn't expect it to be relevant either.
Also hopefully not relevant but I'm on Insider at home. I believe it's build 18970.
Is there any chance that you're using Debug.Write? I could always run DebugView and see if anything is being written. I mean I know it's an unhandled exception so it's not like there would be any specific debugging info written, but just throwing it out there.
Currently no, unhandled exceptions aren't caught at all at the moment but when I get some free time after this weekend I'll add a handler to catch and log them.
Currently no, unhandled exceptions aren't caught at all at the moment but when I get some free time after this weekend I'll add a handler to catch and log them.
This will probably never come up again for anyone else. I broke things in a very unusual way.
I had the clever idea to make a junction in the subfolder for findall\data to my NAS so that my wife and I can share findall items (IE - searching each other's inventory).
I don't autoload findall, and apparently the cached login wasn't working.
It appears Ashita was crashing while trying to follow that junction reference.
Not clear to me why Ashita wasn't auditing the folder before and now it is. It's clearly not a post-update check-up, since manually installing the new DLL didn't change the behaviour.
Anyway, it makes for a fun story. Never underestimate the ingenuity of stupid people to break your shit in unexpected ways.
Thanks for everything!
Okay, I figured out the problem.
This will probably never come up again for anyone else. I broke things in a very unusual way.
I had the clever idea to make a junction in the subfolder for findall\data to my NAS so that my wife and I can share findall items (IE - searching each other's inventory).
I don't autoload findall, and apparently the cached login wasn't working.
It appears Ashita was crashing while trying to follow that junction reference.
Not clear to me why Ashita wasn't auditing the folder before and now it is. It's clearly not a post-update check-up, since manually installing the new DLL didn't change the behaviour.
Anyway, it makes for a fun story. Never underestimate the ingenuity of stupid people to break your shit in unexpected ways.
Thanks for everything!
Haha, this is actually on the list of things to fix in Ashita v4 when its ready already. Same issue happens just trying to run from a network drive in general without any kind of symlink or similar.
No worries and glad you figured out the cause. Will hopefully be a fixed issue in the near future once v4 is ready. :)
Haha, this is actually on the list of things to fix in Ashita v4 when its ready already. Same issue happens just trying to run from a network drive in general without any kind of symlink or similar.
No worries and glad you figured out the cause. Will hopefully be a fixed issue in the near future once v4 is ready. :)
I got the updated release files today. The updated Ashita.dll downloads but the launcher sits at 100% and then silently exits. Subsequent executions have it simply timing out after checking for updates. Looks like an unhandled exception.
Doesn't seem to be affecting my wife's PC, just mine.
Application: Ashita.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.IOException
at System.IO.__Error.WinIOError(Int32, System.String)
at System.IO.FileStream.Init(System.String, System.IO.FileMode, System.IO.FileAccess, Int32, Boolean, System.IO.FileShare, Int32, System.IO.FileOptions, SECURITY_ATTRIBUTES, System.String, Boolean, Boolean, Boolean)
at System.IO.FileStream..ctor(System.String, System.IO.FileMode, System.IO.FileAccess, System.IO.FileShare)
at System.IO.File.Open(System.String, System.IO.FileMode, System.IO.FileAccess)
at Ashita.Model.DownloadTask.DoTask()
at Ashita.ViewModel.MainWindowViewModel+d__12.MoveNext()
at System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.b__6_1(System.Object)
at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
Faulting application name: Ashita.exe, version: 3.1.0.3, time stamp: 0x5b5d3a76
Faulting module name: KERNELBASE.dll, version: 10.0.18975.1000, time stamp: 0xd42c49c4
Exception code: 0xe0434352
Fault offset: 0x0011db62
Faulting process id: 0x31e0
Faulting application start time: 0x01d566bcf309c37a
Faulting application path: D:\Program Files (x86)\Ashita\Ashita.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report Id: f830b574-2933-447d-8e30-a2a81cce8e65
Faulting package full name:
Faulting package-relative application ID:
Make sure of the following:
Generally the only reason it'll sit at 100% and die out would be not having proper write permissions or an anti-virus trying to remove the file or taking forever 'scanning' it.
Ashita's been running perfectly fine until the last update to Ashita.dll. I downloaded the last build from 2 months ago and set --noupdate, and it runs normally again.
It might be relevant that I run Ashita from D:, and when I copy it to %ProgramFiles(x86)% on C:, it does launch.
The last update we pushed was to fix a bug with the resource parser. That won't have any affect on Ashita updating properly in the launcher. Generally, issues like this are due to something on your system preventing the dll from being deleted and replaced. The download can be directly accessed via:
https://git.ashitaxi.com/Ashita/Ashitav3-Release/raw/branch/master/Ashita.dll
You can test and see if there are issues with the direct link too for you. At this time, no one has reported any issues and all the machines and VMs I've tested on have no issues getting the update, so this leads me to believe the issue is on your end.
If you don't mind telling me, what's the full path to where you have Ashita.exe installed at? I'll try and recreate the same environment as you to see if there are issues with the path.
We do recommend that Ashita be installed to the root path of a drive, generally C:\Ashita\ when possible. However, it should work from D:\Ashita\ and so on as well as long as you have proper permissions to the drive.
Also if possible, could you open the 'Event Viewer' on your system and try to locate the crash information inside of that and paste that here too? That should include a bit more details on the crash outside of the main exception code. '0xe0434352' just means 'unhandled exception' so the sub-codes that will be in the event viewer may hold some better information.
I'll give it a try tonight, but it looked like the updated DLL was replaced fine. I didn't compare checksums but I could do that.
The path I'm using is D:\Program Files (x86)\Ashita\ . I can't confirm offhand but I believe I have it installed to the same path on my wife's PC and she hasn't had any issues either. I wouldn't expect it to be relevant either.
Also hopefully not relevant but I'm on Insider at home. I believe it's build 18970.
Is there any chance that you're using Debug.Write? I could always run DebugView and see if anything is being written. I mean I know it's an unhandled exception so it's not like there would be any specific debugging info written, but just throwing it out there.
Currently no, unhandled exceptions aren't caught at all at the moment but when I get some free time after this weekend I'll add a handler to catch and log them.
Well, if they were caught, then they wouldn't be unhandled. ;)
I'm trying the manually downloaded DLL now.
Okay, I figured out the problem.
This will probably never come up again for anyone else. I broke things in a very unusual way.
I had the clever idea to make a junction in the subfolder for findall\data to my NAS so that my wife and I can share findall items (IE - searching each other's inventory).
I don't autoload findall, and apparently the cached login wasn't working.
It appears Ashita was crashing while trying to follow that junction reference.
Not clear to me why Ashita wasn't auditing the folder before and now it is. It's clearly not a post-update check-up, since manually installing the new DLL didn't change the behaviour.
Anyway, it makes for a fun story. Never underestimate the ingenuity of stupid people to break your shit in unexpected ways.
Thanks for everything!
Haha, this is actually on the list of things to fix in Ashita v4 when its ready already. Same issue happens just trying to run from a network drive in general without any kind of symlink or similar.
No worries and glad you figured out the cause. Will hopefully be a fixed issue in the near future once v4 is ready. :)