remoteapptool icon indicating copy to clipboard operation
remoteapptool copied to clipboard

Illegal operation attempted on a registry key that has been marked for deletion AND "Name must not be blank." after selecting my .exe with the file selector.

Open cthart opened this issue 3 years ago • 8 comments

I get the following when attempting to save any new RemoteApp.

See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text ************** System.IO.IOException: Illegal operation attempted on a registry key that has been marked for deletion.

at Microsoft.Win32.RegistryKey.Win32Error(Int32 errorCode, String str) at Microsoft.Win32.RegistryKey.CreateSubKeyInternal(String subkey, RegistryKeyPermissionCheck permissionCheck, Object registrySecurityObj, RegistryOptions registryOptions) at Microsoft.Win32.RegistryKey.CreateSubKey(String subkey) at RemoteAppLib.SystemRemoteApps.SaveApp(RemoteApp RemoteApp) at RemoteApp_Tool.RemoteAppEditWindow.SaveRemoteApp(String ShortName, String FullName, String Path, String VPath, String CommandLine, Int32 CommandLineSetting, String IconPath, Int32 IconIndex, Int32 ShowInTSWA) at RemoteApp_Tool.RemoteAppEditWindow.SaveAndClose() at RemoteApp_Tool.RemoteAppEditWindow.SaveButton_Click(Object sender, EventArgs e) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

************** Loaded Assemblies ************** mscorlib Assembly Version: 4.0.0.0 Win32 Version: 4.8.4180.0 built by: NET48REL1LAST_B CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll

RemoteApp Tool Assembly Version: 5.3.0.0 Win32 Version: 5.3.0.0 CodeBase: file:///C:/Program%20Files%20(x86)/RemoteApp%20Tool/RemoteApp%20Tool.exe

Microsoft.VisualBasic Assembly Version: 10.0.0.0 Win32 Version: 14.8.4084.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll

System Assembly Version: 4.0.0.0 Win32 Version: 4.8.4084.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll

System.Core Assembly Version: 4.0.0.0 Win32 Version: 4.8.4180.0 built by: NET48REL1LAST_B CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll

System.Windows.Forms Assembly Version: 4.0.0.0 Win32 Version: 4.8.4084.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll

System.Drawing Assembly Version: 4.0.0.0 Win32 Version: 4.8.4084.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll

System.Configuration Assembly Version: 4.0.0.0 Win32 Version: 4.8.4084.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll

System.Xml Assembly Version: 4.0.0.0 Win32 Version: 4.8.4084.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

System.Runtime.Remoting Assembly Version: 4.0.0.0 Win32 Version: 4.8.4084.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Remoting/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll

RemoteAppLib Assembly Version: 1.0.0.1 Win32 Version: 1.0.0.1 CodeBase: file:///C:/Program%20Files%20(x86)/RemoteApp%20Tool/RemoteAppLib.DLL

IconLib Assembly Version: 0.73.0.0 Win32 Version: 0.73.0.0 CodeBase: file:///C:/Program%20Files%20(x86)/RemoteApp%20Tool/IconLib.DLL

************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled.

For example:

When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box.

cthart avatar Jul 11 '20 09:07 cthart

Can I get you to run the following command: winver and let us know the exact windows build version you are on?

Also, is this windows home, pro, enterprise, etc? And lastly, are you an administrator on your machine?

MrBrianGale avatar Jul 13 '20 17:07 MrBrianGale

Running the absolute latest version of Windows 10 Pro with all updates installed.

Winver reports Version 2004 (OS Build 19041.329)

Yes, I'm an Administrator.

On Mon, Jul 13, 2020 at 7:18 PM Mr. Brian Gale [email protected] wrote:

Can I get you to run the following command: winver and let us know the exact windows build version you are on?

Also, is this windows home, pro, enterprise, etc? And lastly, are you an administrator on your machine?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kimmknight/remoteapptool/issues/24#issuecomment-657685190, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJHP7NCQWSYGQB5UX4NLM3R3M6UPANCNFSM4OXG7WGA .

cthart avatar Jul 14 '20 07:07 cthart

Can I get you to try this build and let me know if you have the same issues: https://github.com/MrBrianGale/remoteapptool/releases/tag/CreateIcon

I don't think I did anything that would fix it, but it could be that build 5.4.0.0 fixed the issue you are experiencing and my builds are have a base build of 5.4.0.0.

MrBrianGale avatar Jul 14 '20 14:07 MrBrianGale

Hmm, that seems to work!

I do get "Name must not be blank." after selecting my .exe with the file selector.

Then I fill in a name and it saves OK.

Thanks!

/Colin

On Tue, Jul 14, 2020 at 4:02 PM Mr. Brian Gale [email protected] wrote:

Can I get you to try this build and let me know if you have the same issues: https://github.com/MrBrianGale/remoteapptool/releases/tag/CreateIcon

I don't think I did anything that would fix it, but it could be that build 5.4.0.0 fixed the issue you are experiencing and my builds are have a base build of 5.4.0.0.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kimmknight/remoteapptool/issues/24#issuecomment-658198267, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJHP7M4D76FSPZEEYSJD6TR3RQOZANCNFSM4OXG7WGA .

cthart avatar Jul 14 '20 14:07 cthart

Ok, sounds like it is partially fixed in 5.4.0.0 then (or possibly my specific build). I will work on getting this fixed properly and let you know when I have a better solution as getting an error message shouldn't happen, even if it is safe to ignore. Out of curiosity, do you get the same error message if you try to make a remoteapp for a common program such as Notepad.exe? I am wondering if it might be something with that specific EXE you are working with or if it is a bug thanks to the latest Windows 10 update.

MrBrianGale avatar Jul 14 '20 17:07 MrBrianGale

I did some testing and at the moment I am not able to reproduce the problem. My thoughts are that in the latest main branch release, this may be fixed?

I have tried multiple things that I can think of on my Windows 10 home machine and I cannot get that "Name must not be blank" UNLESS I click on "save" while the name is blank.

I am thinking this is likely fixed in a different build. Not sure exactly which commit fixes it, but the next major release should resolve this completely.

MrBrianGale avatar Jul 20 '20 00:07 MrBrianGale

Sorry I didn't get back to you.

I can't reproduce the bug with any other program than the ESU LokProgrammer software. I'm guessing the executable doesn't have the metadata populated causing the error. When comparing the metadata with that of other programs, I see that "File description" is blank -- is that what you are looking at? Maybe fallback to another field, eg "Product name", and if that's also empty populate with the name of the executable minus .exe ? Or are you already doing all this?

If you want to test yourself, you can download and install this software from: http://www.esu.eu/en/downloads/software/lokprogrammer/ I've produced the error with both 5.0.x series and 4.7.2 You don't need the LokProgrammer hardware for the software to work.

Thanks,

Colin

On Mon, Jul 20, 2020 at 2:10 AM Mr. Brian Gale [email protected] wrote:

I did some testing and at the moment I am not able to reproduce the problem. My thoughts are that in the latest main branch release, this may be fixed?

I have tried multiple things that I can think of on my Windows 10 home machine and I cannot get that "Name must not be blank" UNLESS I click on "save" while the name is blank.

I am thinking this is likely fixed in a different build. Not sure exactly which commit fixes it, but the next major release should resolve this completely.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kimmknight/remoteapptool/issues/24#issuecomment-660732561, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJHP7MRKK5OIRPZALWZ6UTR4ODQ5ANCNFSM4OXG7WGA .

cthart avatar Jul 20 '20 09:07 cthart

Glad to hear it is a single program. AND thanks for sending the specific application too. I can grab a copy of that and work on it. I think I know how to fix that without too much trouble. What I am thinking of doing is if the expected field is blank in the app properties, then it will use the filename for any required fields. This is a bit safer than guessing and trying other fields and hoping to find one with a value that we THINK is going to be valid. The other problem with failing through a bunch of different values is that it will be slow doing that and more error prone if the field doesn't exist for example. Having a single fail-back is going to be faster and failing back to a "known good" value (filename without extension) will be the safest option.

I will have some time to work on this this week and should have something for Friday if not sooner.

MrBrianGale avatar Jul 21 '20 15:07 MrBrianGale