[Solved] Run command not working any longer-"Error creating process.."/error 193

[otoien]

At some point in the transition to 1.8 or 1.8.2 the run command has stopped working for me. The symptoms are that I cannot launch an application with the run command in a project located under my home folder.

Code: Pascal  [Select][+][-]

1. The GDB command:"-exec-run" returned the error:
2. ",msg="Error creating process D:/Oivind Toien/Documents/LazarusProjects/ProConvert/ProConvert.exe, (error 193).""

This happens whatever project I try it out with. But the build works fine and I can launch the application by clicking the executable in the project folder after build. Also if I move the project folder to the root of the C drive, the run command will work. This looks like the problem in this old thread:
http://forum.lazarus.freepascal.org/index.php/topic,36349.msg242068.html#msg242068
The problem identified there is a space in the path of the executable file. However there is no alternative for me to rename my home folder to something without space in it as it will affect everything else on the computer, and this is a clear regression compared to how it worked previously.

I am not completely sure this is version related, as I thought I previously checked out if both version 1.82 and 1.8.0 (tried both now without luck) after I installed them, but I have not found a way for the path of the application executable to have quotation marks which presumably would fix the problem. The content of the run parameter dialog is blank as on the help page. The Run Command in the Configure Build About.pas  Run tab is $MakeExe($(EdFile)).

[taazz]

the easy way out although not what it was asked is to not use your documents folder for your applications start a new folder in c:\Lazarusprojects\Proconvert\. that should solve the problem I guess. Sorry not much of a gdb guy, but have you tried to change the Run command to $Makeexe("$(EdFile)")?

[otoien]

Thanks for the suggestions, taazz. Unfortunately the insertion of the quotation marks in the run command had no effect, exactly the same error message.

The other suggestion might be a fallback solution, but I would like to avoid it if I can as it will complicate my backup routines. I am rather confused as to how this error has shown up, since it has been working normally for years. As I am pretty sure that it worked normally when I upgraded to 1.8.0 or one of the 1.8.0 RCs, but not now, it could perhaps be a change in some setting that was introduced with the later versions (I have not been very active lately, so mostly checked out old projects). Or could there have been a silent Windows update in the mean time that has messed things up? the folders under my home folder are fully writable though and I have full privileges, I even tried "run as administrator" without any improvement.

Perhaps I should try a full uninstall and a clean reinstall without using old settings files. It could be interesting to hear though if anyone has success with the run command even if they have spaces in any of the folders in the path of the project folder. 

Update while editing: The theory about problems with space in the folder path is not supported. I tried to create a folder 'C:\Lazarus Projects' and placed the project folder under it. Both the build and the run command worked well.
I also copied my whole "LazarusProjects" folder from my home folder to C:\ and that also worked. 

Update2: I did a complete uninstall, removed project settings (after backing them up) and did a clean install of 1.8.0- RC1. Did the same with 1.8.0 RC4. Still no success with the run command. It is highly unlikely that I did not check these out previously and had them working. Thus it is highly unlikely that it is related to the Lazarus version. There seems to be some change that has happened to the folder tree under my home directory. Thus I have now reverted back to 1.8.2 with cross compiler and anchor docking support and successfully recompiled Lazarus, using the old settings. I also recreated the project folder under my home directory and copied files back, but no luck. Could there be some additional security has been introduced in a Win7 professional update that prevents an application under the home folder to be launched by another application? Anyone else seeing this?

[Martin_fr]

Code: Pascal  [Select][+][-]

1. The GDB command:"-exec-run" returned the error:
2. ",msg="Error creating process D:/Oivind Toien/Documents/LazarusProjects/ProConvert/ProConvert.exe, (error 193).""

http://forum.lazarus.freepascal.org/index.php/topic,36349.msg242068.html#msg242068
The problem identified there is a space in the path of the executable file.

http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Error_193_.28Error_creating_process_.2F_Exe_not_found.29

Afaik the error is not just the space. But a 2nd path (in your case D:/Oivind  exists.
Do you have such a path? Recently created?

If so, there is no known way around.

[Thaddy]

Note windows has the GetShortPathname api to solve the space problem. It is in the Windows unit.
See https://msdn.microsoft.com/en-us/library/windows/desktop/aa364989(v=vs.85).aspx
That will remove both issues, since this api guarantees a spaceless, but unique path to the same longpathname path.

Note there is no regression: this has always been the case since gdb does not handle long path names with spaces.
What Lazarus *could* do is use this api to call gdb on Windows, but that is a feature request. (Which I already asked for  years ago if memory served me right)

Second option is to create a symlink or junction for the path(s) that does not contain the spaces.

[otoien]

Thanks so much Martin_fr (and Thaddy)! Although the web page points to XP, lo and behold, there was a file (not a folder) on D:\ named 'Oivind' that another application I just tested days ago had created without my knowledge. I removed the file and problem solved!

So yes, no "regression" as it was caused by the file and could have happened at any time; it all makes sense now. I think I might try to contact the author of the application and point out the possibility that it can create problems.

Apparently the spaces in the path by itself does not create problems as long as there is no confusion. It is strange though that a file in this case was interpreted as part of a folder name.

[Thaddy]

Apparently the spaces in the path by itself does not create problems as long as there is no confusion. It is strange though that a file in this case was interpreted as part of a folder name.

That is not - and never has been - strange or the case: under windows, a path that contains spaces should be passed within double quotes, - otherwise the path will break at the space. BTW that is option 3. And this one does not always work with external tools like GDB anyway.
But is is easily fixed with options 1 and 2.

(ad 3: note there is a cmd option now that does this basically for you, but still doesn't help you because gdb is the cause.)

See: https://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/  for example. This will work for any GNU based tools including gdb.

[otoien]

Thanks for further info Thaddy. I will keep the information in mind if I get into trouble again. As for now it should be easy to avoid, as the offending file looked like some kind of log file, or a temporary file used to transfer a command to a command line application from a GUI. Also the application will likely see only very sporadic use, if any.