Issue starting brand new projects

koahnig

@mrjj @kshegunov
It gets more ridiculous.

Reopened the large session (has 20 entries BTW). Opened another test project and now all works again.

However, a bit more testing showed that it might have been the naming of the project. I used always "Setup" in the name. Before i had often removed my failures. This time I made sure that the project name was new "SetupHelping", it failed again.
When creating another project with the name "S_E_T_U_P_Helping" it works.

That is really ridiculous.

kshegunov

@koahnig
That indeed sounds ridiculous. I tried on my machine and it works fine, but I wouldn't expect problems, as I'm developing on Linux (Qt Creator 3.6.1 if you're wondering).

Any updates on Qt/Qt Creator when you changed the windows version?
What about Win10 security policies and/or antivirus software, those could be interfering with the debugger?
I think MS introduced some changes with the security in Win10, and I believe it also reflects the debugging APIs, so perhaps it's worth taking a look into that? One thing you could also try is to start a console debugging session with gdb and see if it starts okay. If it doesn't I'd search for some debugger/OS incompatibility.

mrjj

@koahnig said:
SetupHelping

Wow. That I never would have guess in a million years.
I can reproduce it.
If I make brand new project and name it SetupHelping
it cannot run.
and
"Failed to start program. Path or permissions wrong?"

Win 10, Qt 5.6. mingw

kshegunov

@mrjj

That I never would have guess in a million years.

Neither would have I.

I can reproduce it ... Win 10, Qt 5.6. mingw

What about the creator version? Can you perhaps start the application directly (not through creator/debugger)? Can you "run" it in creator without debugger? Can you start a console debugging session?

mrjj

@kshegunov said:
It cannot run from creator at all.
I can start it in in deploy folder.

koahnig

@mrjj @kshegunov
I am using a self-compiled Qt creator 3.1.2 (rather old and compiled with MinGW 4.8.2 32 bit). Qt version 5.4.1 and 5.3.1 precompiled.

I thought already that the issue has something to do with my AV-scanner bitdefender.

@mrjj Which are you using?

Possibly it could be the windows defender stuff too.

It is the TARGET name you have to change. Simply changed in .pro to "TARGET = S_e_t_u_p_Helping" or "TARGET = Set_upHelping" and it works.

kshegunov

@mrjj
That is very, very strange ...

@koahnig
To be honest I'm running out of ideas ... perhaps putting the target name into a variable (I quoted it to be sure) ...?

MY_TARGET_NAME = "SetupHelping"
TARGET = $(MY_TARGET_NAME)

koahnig

@kshegunov
You are the only one on Linux. So, possibly limited to Windows or even Win10.

@kshegunov said:

MY_TARGET_NAME = "SetupHelping"
TARGET = $(MY_TARGET_NAME)

This does not do the trick.

kshegunov

@koahnig

You are the only one on Linux. So, possibly limited to Windows or even Win10.

I'd even say probable. I don't experience any strange behavior by changing the target to the problematic one.

This does not do the trick.

Well, my "shot in dark" approach has met its demise ... sadly I have nothing further to suggest. :|

mrjj

it doesn't even like
e:\build-mysetup-Desktop_Qt_5_6_0_MinGW_32bit-Debug\debug\mysetup.exe

I mean mysetup. ?!

occult name. i say..

Maybe others with win 10 can try.

hskoglund

Hi, I remember Windows can be very sensitive to .exe filenames containing the words "setup" or "update", see discussion here

koahnig

@hskoglund
I was also my guess that it is a windows/AV scanner issue. However @mrjj could start the exe in the deploy folder. See further above.

mrjj

Hi
Just for test.
On windows 7, you can name it anything setup.
Still runs.

So its a win 10 feature. :)
Tonight I will reset my UAC and see if it actually try to warn.

hskoglund

Hi, just tested with an empty widgets app, named TestSetup :-)

Compile/building it with a Microsoft compiler, for example MSVC2013 or MSVC2015 (32-bit or 64-bit same result) will give you an .exe which you can start both from Qt Creator and from File Explorer, without anyone complaining, in any version of Windows.

However compile/build with a MinGW compiler, for example 4.9.2 32-bit, will give you an .exe file that will fail to start from Qt Creator and give you a UAC prompt when started from File Explorer in Windows 7, Windows 8 and Windows 10 (but not in Windows XP).

The reason is that the MinGW does not include a manifest XML file, the crucial part of the manifest is this part:

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level='asInvoker' uiAccess='false' />
      </requestedPrivileges>
    </security>
  </trustInfo>

(i.e. if I blank out that text in the .exe file which was compiled with a MSVC compiler, it will then also give you a UAC prompt.)

kshegunov

@hskoglund
Doesn't this mean you're bound to use the M$ compiler (if there isn't a way to generate and embed the manifest with MinGW)? If so, this'd be terrible ...

mrjj

@kshegunov

But funny enough, it works on my win 7, Qt 5.5 and mingw :)
Here at work.

kshegunov

@mrjj
Yep, windows is funny that way. ;)
You probably had disabled the "new security features" at some point in the past, and that's why it works.

mrjj

@kshegunov
Yes, I have obligated the UAC on win 7. ( User Annoying Component ;)

Will try the same on win 10 if still possible.