Crash decrypting strings encrypted in different environment

@gbakeman

Please make sure to fill out this form completely, and attach your program logs (set to Debug setting). You can delete this line.

Searched to see if this issue exists
[ X] Completed below form
[ X] Attached debug log file
Copy output in File -> UPS Variable

**WinNUT Version: 2.3..9437.23054
**Windows OS Version: Server 2025

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

Go to - Run on Server 2025 seems to crash, on first run.

Expected behavior
Program should load the GUI

Additional context
Add any other context about the problem here.

CrashReport_2025-11-10T10.56.20.txt

@gbakeman's Addendum

Exception

{
  "ClassName": "System.Security.Cryptography.CryptographicException",
  "Message": "Key not valid for use in specified state.
",
  "Data": null,
  "InnerException": null,
  "HelpURL": null,
  "StackTraceString": "   at System.Security.Cryptography.ProtectedData.Unprotect(Byte[] encryptedData, Byte[] optionalEntropy, DataProtectionScope scope)
   at WinNUT_Client_Common.SerializedProtectedString.Unprotect(String protectedString) in C:\Users\Glen\Repositories\nutdotnet\WinNUT-Client\WinNUT_V2\WinNUT-Client_Common\SerializedProtectedString.vb:line 75
   at WinNUT_Client_Common.SerializedProtectedString.ToString() in C:\Users\Glen\Repositories\nutdotnet\WinNUT-Client\WinNUT_V2\WinNUT-Client_Common\SerializedProtectedString.vb:line 84
   at WinNUT_Client.WinNUT.UPS_Connect(Object retryOnConnFailure) in C:\Users\Glen\Repositories\nutdotnet\WinNUT-Client\WinNUT_V2\WinNUT-Client\WinNUT.vb:line 370
   at WinNUT_Client.WinNUT.WinNUT_Shown(Object sender, EventArgs e) in C:\Users\Glen\Repositories\nutdotnet\WinNUT-Client\WinNUT_V2\WinNUT-Client\WinNUT.vb:line 250
   at System.Windows.Forms.Form.OnShown(EventArgs e)
   at System.Windows.Forms.Form.CallShownEvent()
   at System.Windows.Forms.Control.InvokeMarshaledCallbackDo(ThreadMethodEntry tme)
   at System.Windows.Forms.Control.InvokeMarshaledCallbackHelper(Object obj)
   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.Windows.Forms.Control.InvokeMarshaledCallback(ThreadMethodEntry tme)
   at System.Windows.Forms.Control.InvokeMarshaledCallbacks()"

hmm, uninstall re-install fixed the issue :).

ahh and now I know what caused it. When you copy the user.config from another server it breaks the install.

ahh and now I know what caused it. When you copy the user.config from another server it breaks the install.

But it would load the next time OK with the same user config? Could you please provide that config file (with sensitive information redacted)?

Once I copy the config from a working machine, WinNut no longer will load. The only way to fix it, is to uninstall it and re-install it. I did notice there was mention of a backup and restore function but I couldn't find it. I think I redacted everything I needed too.
*Edit - if I delete the the c:\users%username%\appdata\NUTDotNet folder it will also fix the installation.

user.config.txt

@aarnold-sd68

Hi @aarnold-sd68 ,

Thanks again for providing the previous info. It looks like it's a simple bug. I have the username and password encrypted using standard Windows APIs, and when this information is moved to a new machine, it throws an error that I didn't think to catch. Should be a simple fix too. I'm thinking I'll put a line in the GUI message log stating that the username/password is invalid and has been cleared/reset. Does that sound like a decent fix?

I also wanted to add: you're right that there is a settings import function, but that was only to bring over previous WinNUT configurations that were stored in the Registry. There is an issue open in #121 for a full export/import function, subscribe there for more info.

That sounds like a good fix to me.

Finally got a PR up and build is building now. If you get a chance to test I'd appreciate it, but in my own testing I'm fairly confident that this issue has been fixed so I may deploy a pre-release soon. Thanks again for your feedback and assistance!

Build no longer crashes when you initially copy over the config, I did have to copy the config over to a version 1.0.0.0 folder rather then the 2.3.9437... folder . But when I enabled the logging the system crashed, but does seem to leave the create logfile enabled when reloaded. Will continue to crash if the create log is enabled when making changes to other miscellaneous config items. Not sure if this is related or a different bug. I'd copy the bug report but it closes too quickly to grab.
Here's the event log entry:
Application: WinNUT-Client.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.InvalidCastException
at Microsoft.VisualBasic.CompilerServices.Conversions.ToString(System.Object)
at WinNUT_Client.My.MyApplication.GenerateCrashReport(System.Exception)
at WinNUT_Client.My.MyApplication.MyApplication_UnhandledException(System.Object, Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs)
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.raise_UnhandledException(System.Object, Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs)
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnUnhandledException(Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs)
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnUnhandledExceptionEventAdaptor(System.Object, System.Threading.ThreadExceptionEventArgs)
at System.Windows.Forms.Application+ThreadContext.OnThreadException(System.Exception)
at System.Windows.Forms.Timer+TimerNativeWindow.OnThreadException(System.Exception)
at System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef)
at System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
at System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
at System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun()
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel()
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(System.String[])
at WinNUT_Client.My.MyApplication.Main(System.String[])

I'm glad to hear that the first crash seems to have been fixed! Apologies for the unexpected folder location, that's a temporary location used for debug builds. I have to admit that I'm mystified by this new crash you're experiencing.

I'm having a hard time finding where in the GenerateCrashReport subroutine it could be calling a VB-specific ToString conversion, so I'm a bit stumped on why that would be crashing. In addition, I've tried switching various settings (including logging) on and off using the config file you provided and can't produce a crash that way either.

I've made a few tweaks to how unhandled exceptions are handled in WinNUT and made a new debug build here. Would you please give it another try and see if it operates any differently?

Ok. found the issue. It's a permissions issue, now that I can see the output. it's trying to write to the installation path, and I didn't run it as administrator. ok that's an easy fix on my part, sorry for the miss diagnosed error. The weird part is the previous version didn't crash when I did the very same thing.

CrashReport_2025-12-09T10.53.25.txt

Thanks again for your testing and reports! I'm sure I changed something before that might've made log file generation more unstable. This has led me to catching a few more bugs, and I'm making another attempt at approaching how WinNUT handles log files to be a little more robust. Sorry this is taking so long.

Thanks again for your testing and reports! I'm sure I changed something before that might've made log file generation more unstable. This has led me to catching a few more bugs, and I'm making another attempt at approaching how WinNUT handles log files to be a little more robust. Sorry this is taking so long.

Take your time, I'd rather it take a little longer and get it right then rush and get more bugs :).

Thanks for your patience while I pulled this all together. I modified how WinNUT generates log files so it should always locate a writable folder when one is needed. I'm pushing forward with making a release since I know several people have been patiently waiting on one. I believe this fixes the immediate crash you noticed, although I'm afraid there still may be one lurking. Please let me know if you notice any more issues!

I was having the same issue, after I overclocked my pc and a BSOD occurred once the WinNUT had this error, reinstalling WinNUT didn't fix, also my pc password changed and Edge Browser was disconfigured (something very wrong happened during the BSOD haha), anyways, I had to delete the user.config file and it's working now.

@SoldierDragon

@SoldierDragon I'm sorry to hear about the data corruption incident, I hope you were able to recover everything you needed. As far as a WinNUT error, did you see the same crash as the OP did? What version were you running at the time?

@gbakeman

@gbakeman yes, same error, I was able to fix everything, I was running the Release v2.2.8719, I tried installing the latest version and it didn't work, only deleting the config folder fixed the issue

Navigation Menu

Repository navigation

Crash decrypting strings encrypted in different environment #224

@gbakeman's Addendum

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Crash decrypting strings encrypted in different environment #224

Description

@gbakeman's Addendum

Activity

aarnold-sd68 commented on Nov 10, 2025

aarnold-sd68 commented on Nov 10, 2025

gbakeman commented on Nov 10, 2025

aarnold-sd68 commented on Nov 10, 2025

gbakeman commented on Nov 18, 2025

aarnold-sd68 commented on Nov 18, 2025

gbakeman commented on Dec 6, 2025

aarnold-sd68 commented on Dec 8, 2025

gbakeman commented on Dec 9, 2025

aarnold-sd68 commented on Dec 9, 2025

gbakeman commented on Dec 12, 2025

aarnold-sd68 commented on Dec 12, 2025

gbakeman commented on Dec 27, 2025

SoldierDragon commented on Sep 29, 2026

gbakeman commented on Oct 2, 2026

SoldierDragon commented on Oct 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions