A newe weirdness with latest update. Old program no longer functions properly.

Win-10-64-Pro !) vers. 10.0.16289.248

I use an old reminder program named Eventmanager by Rotabeta software
(now apparently defunct).

Until the last upgrade it worked fine. It is set to run on startup,
where it displays a splash screen and then runs in the background,
producing a pop-up window for stored events at the appropriate date
and time.

Now I just discovered it runs a splash screen and then stops running
altogether. Compatibility settings haven't helped.

Now here is the weirdness. The software is distributed in a zip file.
There is no installer or installation process. Just put it in a
folder, and run the exe file.

SO, if I go to that folder and run the exe file, I get the splash
screen and no program. BUT if I click on the exe file in the 7-zip
screen, it runs just fine.

I found that 7-Zip puts it in a temporary appdata file under
/users/me. Going to that directory and clicking on the exe file there
again results in splash screen, immediate exit.

Any idea how to get it to again run properly from a disk directory
without having to start it in the zip file?

satireI just LOVE Windows 10!!!/satire

-dan z-


--
Someone who thinks logically provides
a nice contrast to the real world.
(Anonymous)

slate_leeper wrote:
Win-10-64-Pro !) vers. 10.0.16289.248

I use an old reminder program named Eventmanager by Rotabeta software
(now apparently defunct).

Until the last upgrade it worked fine. It is set to run on startup,
where it displays a splash screen and then runs in the background,
producing a pop-up window for stored events at the appropriate date
and time.

Now I just discovered it runs a splash screen and then stops running
altogether. Compatibility settings haven't helped.

Now here is the weirdness. The software is distributed in a zip file.
There is no installer or installation process. Just put it in a
folder, and run the exe file.

SO, if I go to that folder and run the exe file, I get the splash
screen and no program. BUT if I click on the exe file in the 7-zip
screen, it runs just fine.

I found that 7-Zip puts it in a temporary appdata file under
/users/me. Going to that directory and clicking on the exe file there
again results in splash screen, immediate exit.

Any idea how to get it to again run properly from a disk directory
without having to start it in the zip file?

satireI just LOVE Windows 10!!!/satire

-dan z-

How does it behave if you unpack the ZIP first to
separate files ? Maybe the thing is a SFX (an EXE
that unpacks on the fly?).

If I was there, I would be testing the ZIP and/or
the components inside it, on virustotal.com, to see if
any of the scanners get a false positive. It would
at least suggest whether the AV industry isn't
handling that format or method well.

Paul

On Thu, 10 May 2018 18:03:00 +0100, Good Guy
wrote:



Have you tried putting the exe file in your startup folder?


It has always been in the startup folder. That is kind of necessary to
get notification reminders when they are due.

That is also why I didn't notice it wasn't working right away -- it
still showed the splash screen after each reboot.



--
Someone who thinks logically provides
a nice contrast to the real world.
(Anonymous)

On Thu, 10 May 2018 15:37:00 -0400, Paul
wrote:


How does it behave if you unpack the ZIP first to
separate files ? Maybe the thing is a SFX (an EXE
that unpacks on the fly?).


That is how it always was. Unpacked to a directory in program files.
The eventmanager.exe set for autostart. Worked fine until my last
Win-10 update. I didn't realize it wasn't working at first because the
splash screen still showed after each restart or reboot.

If I click the .exe file in that directory, I get the splash screen.
Task manager shows the program for a few seconds, then it disappears.
If I click the .exe file in the 7-zip window, it starts and stays
running. The only difference in files in the two directories is that
there is an .ini file in the programfiles directory that contains last
windows position and a flag to show only enabled events in the viewer.
However, I removed that .ini file to see if it would help. Nope, it
didn't.


If I was there, I would be testing the ZIP and/or
the components inside it, on virustotal.com, to see if
any of the scanners get a false positive. It would
at least suggest whether the AV industry isn't
handling that format or method well.


I've been using this thing since XP. It has been through a LOT of
scans over the years, with several different anti-virus products.

It does appear that the exe file is also a packed file of some type.
It looks like two data files and a compressed program file, as near as
I can tell. Like it's supposed to uncompress on execution.

I still don't understand why it works from within the 7-zip folder,
but not anywhere else.

-dan z-


--
Someone who thinks logically provides
a nice contrast to the real world.
(Anonymous)

slate_leeper wrote:
On Thu, 10 May 2018 15:37:00 -0400, Paul
wrote:


How does it behave if you unpack the ZIP first to
separate files ? Maybe the thing is a SFX (an EXE
that unpacks on the fly?).


That is how it always was. Unpacked to a directory in program files.
The eventmanager.exe set for autostart. Worked fine until my last
Win-10 update. I didn't realize it wasn't working at first because the
splash screen still showed after each restart or reboot.

If I click the .exe file in that directory, I get the splash screen.
Task manager shows the program for a few seconds, then it disappears.
If I click the .exe file in the 7-zip window, it starts and stays
running. The only difference in files in the two directories is that
there is an .ini file in the programfiles directory that contains last
windows position and a flag to show only enabled events in the viewer.
However, I removed that .ini file to see if it would help. Nope, it
didn't.


If I was there, I would be testing the ZIP and/or
the components inside it, on virustotal.com, to see if
any of the scanners get a false positive. It would
at least suggest whether the AV industry isn't
handling that format or method well.


I've been using this thing since XP. It has been through a LOT of
scans over the years, with several different anti-virus products.

It does appear that the exe file is also a packed file of some type.
It looks like two data files and a compressed program file, as near as
I can tell. Like it's supposed to uncompress on execution.

I still don't understand why it works from within the 7-zip folder,
but not anywhere else.

-dan z-

It could be that 7ZIP is unpacking the file you clicked,
into %temp%.

Places like Program Files and System32 are generally out
of bounds. Any program pretending to install something,
has to use the TrustedInstaller token. Not even Administrator
is supposed to work on those folders. (It's a kind of
security theater, since the Administrator account has
impersonate privileges, and that is how it fires up
TrustedInstaller. TrustedInstaller is not a real account.
It doesn't have a home directory. It shouldn't have a password.
And it's an account that exists as a token, rather than
being a real account.)

Microsoft has had a workaround for a while, that makes programs
living in Program Files work. Some older programs write a .ini
file right into the Program Files folder. For compatibility,
Windows has been moving those writes to a "Roaming" folder.
Somehow, this is supposed to prevent malware from writing
into a Program Files folder, yet still offering an older
program the .ini file it needs at startup.

Using Process Monitor from sysinternals.com (a MS site), you
can start a trace just before clicking your program, and
after the event is done and you stop the trace via the File
menu tick box, you can scroll back and see what the program
is doing.

If you then move to a machine running an older OS (where
your program works), you can compare the high points of
the trace there, to what Windows 10 is doing. And figure
out which "rule" you've violated. The only way we find
out Microsoft has changed something, is via testing.

Paul

On Thu, 10 May 2018 20:02:14 -0400, Paul
wrote:

It could be that 7ZIP is unpacking the file you clicked,
into %temp%.


Yes. The file is located in /user/me/appdata/(something)/temp. If I
then exit the program, and try to restart it from here I get the same
start-then-stop result.


Places like Program Files and System32 are generally out
of bounds. Any program pretending to install something,
has to use the TrustedInstaller token. Not even Administrator
is supposed to work on those folders. (It's a kind of
security theater, since the Administrator account has
impersonate privileges, and that is how it fires up
TrustedInstaller. TrustedInstaller is not a real account.
It doesn't have a home directory. It shouldn't have a password.
And it's an account that exists as a token, rather than
being a real account.)


Actually, the install is in /users/me/program files. Would that have
the same problem as the default C:/program files?

I guess a solution would be to look for another reminder program I
like as much as this one.


-dan z-

--
Someone who thinks logically provides
a nice contrast to the real world.
(Anonymous)

On Thu, 10 May 2018 12:32:15 -0400, slate_leeper
wrote:


To make things even more weird, it is now working just fine. I have no
idea why or what changed....


-dan z-


--
Someone who thinks logically provides
a nice contrast to the real world.
(Anonymous)