Latest Version of Windows 10 + CreateShortcut on Desktop => OLE-Error ???

[StefanFoerner]

Hi eryone,

since the latest update for Windows 10 (version 1709, build 16299.192) you can apparently no longer create a link on the desktop with the Windows Scripting Host method CreateShortcut ...

(Info: in normal folders / subfolders everything works)

WshShell = CreateObject( "Wscript.Shell" )

desktopStr = WshShell.SpecialFolders( "Desktop" )

shortcutObj = WshShell.CreateShortcut( desktopStr + "\Test.lnk" )
	
WITH shortcutObj
	.TargetPath       = "C:\Test\Test.exe"
	.WorkingDirectory = "C:\Test"
	.Description      = "Test-Programm"
	.WindowStyle      = 1
	.Save
ENDWITH

The following error message appears:

OLE IDispatch Exception Code 0 from WshShortcut.Save: The "C:\Users\Memotech\Desktop\Test.lnk" link was not saved ...

Under slightly older Windows 10 versions and under Windows 7 everything still works without any problems and without an error message!

- has anyone noticed this effect already?

- must something be changed at the code sequence above?

Regards, Stefan

 

[Olaf Doschke]

Edition: Windows 10 Home, Version: 1709, Build: 16299.192

Your code works, simply works as is without error.

So either it's a difference of Windows Editions or it's something completely different like a broken OLE Server of WScript.Shell.

Bye, Olaf.

Edit: What's not working for me is the Object Browser of VFP. Not sure how long that's broken, as I use it rather seldom. I wanted to look at Wscript.Shell here to find out details.

Also, the registry tells Wscript.Shell is using wshom.ocx in System32 (or SysWow64) as InProcServer32. The "hom" within the ocx file name maybe really hints on a Home Edition of the WSH Shell, though the h could simply be the h of WSH. My version of the OCX is from 09/29/2017, Version 5.812.10240.16384

 

[StefanFoerner]

My version of Wshom.ocx ist exactly the same !

I assume Wshom = Windows Scripting Host Object Manager

I will check the version of Wshom.ocx on my other PC with the older version of Windows 10

Thankx, Stefan

 

[Olaf Doschke]

depends.exe has some difficulties tracing dependencies of the wshom.ocx, but finally lists two things, which I think are most important: The C runtime MSVCRT.DLL (version 7.0.16299.125) and the SCRRUN.DLL, the Microsoft Script runtime (version 5.812.10240.16834)

Some software you installed might have replaced the msvcrt.dll to some version incompatible with the wshom.ocx

Bye, Olaf.

 

[StefanFoerner]

very good note, but I have exactly the same versions!

First level dependencies of Wshom.ocx:

MSVCRT.DLL - 7.0.16299.125
OLEAUT32.DLL - 6.2.16299.15
OLE32.DLL - 6.2.16299.192
ADVAPI32.DLL - 6.2.16299.192
KERNEL32.DLL - 6.2.16299.15
USER32.DLL - 6.2.16299.125
MPR.DLL - 6.2.16299.15
SHELL32.DLL - 6.2.16299.192
SCRRUN.DLL - 5.812.10240.16384
WINSPOOL.DRV - no version - but date: 29.09.2017 15:42

Regards, Stefan

 

[StefanFoerner]

Update:

- creating the shortcut in "C:\Users\Memotech" works

- creating the shortcut in WshShell.SpecialFolders( "Desktop" ) = "C:\Users\Memotech\Desktop" doesn't work

Also exactly the same behavior on a second PC with same Windows 10 version 1709, build 16299.192

Regards, Stefan

 

[Olaf Doschke]

I have all the same versions. Then it seems to be a permission issue.
I run under the main administrative user, albeit with UAC on. It shouldn't require a special right to create a shortcut on your own Desktop, which I get from WshShell.SpecialFolders( "Desktop" ),unless policies or anything else strip down permissons further.

Any more detail info on the error from AERROR()?
If not, the next thing to do is using process monitor to find out about which calls/actions of the OCX fail. When testing in the IDE the vfp9.exe process has to be monitored, haven't done that in a while, a log should tell you what calls in detail are done into which DLLs or OCXes. You might only be able to correlate via timestamps, so you better do coverage logging additional to process monitoring, so later you can see which line of VFP code was done at which time and corresponds to a part of the process monitor log. The logfile file creation datetime plus individual code line durations VFP logs in its coverage log should match timestamps of process monitor.

Bye, Olaf.

 

[StefanFoerner]

Infos from AERROR( arrayVal ):

(lineVal = AERROR( arrayVal ) returns lineVal = 1)

1: 1429
2: OLE-IDispatch-Ausnahmecode 0 von WshShortcut.Save: Die Verknüpfung "C:\Users\MemoTech\Desktop\Test.lnk" wurde nicht gespeichert...
3: Die Verknüpfung "C:\Users\MemoTech\Desktop\Test.lnk" wurde nicht gespeichert.
4: WshShortcut.Save
5:
6: 0
7: 0

- the Save method fails

- and I agree, this must be a permission issue

- but interactively (right mouse click on windows desktop) I can create a link on the desktop, no problem

Regards, Stefan

 

[StefanFoerner]

Update:

1) creating the shortcut in the current directory works

2) copying this new shortcut from the current directory to the desktop fails. Error 1102: "Datei kann nicht erstellt werden."

COPY FILE "Test.lnk" TO "C:\Users\MemoTech\Desktop\Test.lnk"

Infos from AERROR( arrayVal ):

1: 1102
2: Datei kann nicht erstellt werden.
3: .NULL.
4: .NULL.
5: .NULL.
6: .NULL.
7: .NULL.

- so that is not a problem specially with Windows Scripting Host or Wshom.ocx

Regards, Stefan

 

[Olaf Doschke]

Pitt, no further ole error code.

And MemoTech is the current login? ID() is "computername # memotech"?

That's weird. I think group policies could cause such permissions issues. They're often the forgotten subsystem of permissions aside from folder/file permissions via the access control lists (ACL) of the file system. The question then is, why you can create a link manually, outside of VFP, because group policies also should have a global effect and not selectively allow things in some but not other processes.

There are group policies about desktop shortcuts, e.g. see

https://blogs.technet.microsoft.com...icy-preferences-in-windows-8-and-windows-8-1/

Bye, Olaf.

 

[StefanFoerner]

- yes MemoTech is the current login

- and MESSAGEBOX( ID() ) shows: "ACER-1 # MemoTech", that's correct

I will read Your blogs.technet.microsoft.com link

Thankx, Stefan

 

[Olaf Doschke]

The link just points out there is something about desktop shortcuts in group policies.
But especially for a single computer not in a domain, like in Home editions of Windows, they don't play a role.
If you're running the Enterprise or Ultimate edition, or are in a domain, that might explain the difference.

Bye, Olaf.

 

[StefanFoerner]

- Windows Edition is Windows 10 Home

- no domain, only a workgroup MEMOTECH

maybe there will be soon an update for Windows 10, which fixes the problem ... (???)

Regards, Stefan

 

[StefanFoerner]

Problem solved !!!

that's a (new ???) Windows Defender setting (german): "Überwachter Ordnerzugriff"

Windows Defender Security Center => Viren- & Bedrohungsschutz => Einstellungen für Viren- & Bedrohungsschutz => Überwachter Ordnerzugriff => Off

(this setting does not exist on my machine with the older Windows 10 version)

switching to Off and all works!

Can You take a look at this setting on Your machine?

Regards, Stefan

 

[Olaf Doschke]

I use Bitdefender.

Bye, Olaf.

 

[StefanFoerner]

Ok, that explains the different behavior

Regards, Stefan