Am 15.07.2018 um 08:49 schrieb Marco Atzeri:
Am 14.07.2018 um 21:03 schrieb Brian Inglis:
On 2018-07-14 11:58, Achim Gratz wrote:
Marco Atzeri writes:
it seems the WOW64*.dll can be anywhere between
5000-7F00
The 32 applications present at boot are:
HP Cool Sense
HP Audio Switch
HP
Am 15.07.2018 um 19:23 schrieb David Stacey:
On 15/07/18 07:49, Marco Atzeri wrote:
In this case AVG is innocent.
I removed all AV and the lottery is still there
The 32 applications present at boot are:
Lavasof Webcompanion
We've had trouble with that one in the past [1].
Dave.
[1] - https
Greetings, Marco Atzeri!
> Lavasof Webcompanion
--
With best regards,
Andrey Repin
Sunday, July 15, 2018 20:22:46
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
On 15/07/18 07:49, Marco Atzeri wrote:
In this case AVG is innocent.
I removed all AV and the lottery is still there
The 32 applications present at boot are:
Lavasof Webcompanion
We've had trouble with that one in the past [1].
Dave.
[1] - https://cygwin.com/ml/cygwin-patches/2015-q3/msg000
On 2018-07-15 00:49, Marco Atzeri wrote:
> Am 14.07.2018 um 21:03 schrieb Brian Inglis:
>> On 2018-07-14 11:58, Achim Gratz wrote:
>>> Marco Atzeri writes:
Diese E-Mail wurde von AVG auf Viren geprüft.
>>> might be an explanation for the whole thing. AVG is well known for
>>> intercepting thi
Marco Atzeri writes:
> In this case AVG is innocent.
> I removed all AV and the lottery is still there
Again, if the ASLR setup has been changed via registry, I wouldn't bet
that the uninstallation of the application that changed them to reset
to the defaults (if it was indeed AVG,).
> it seems t
Am 14.07.2018 um 21:03 schrieb Brian Inglis:
On 2018-07-14 11:58, Achim Gratz wrote:
Marco Atzeri writes:
Anyway, the only time I've seen similar behaviour was when some other
library was occupying the address space the systems libraries should
have occupied, and the they get some extremely rand
On 2018-07-14 11:58, Achim Gratz wrote:
> Marco Atzeri writes:
> Anyway, the only time I've seen similar behaviour was when some other
> library was occupying the address space the systems libraries should
> have occupied, and the they get some extremely random address assigned
> until the next reb
Marco Atzeri writes:
> Nothing fancy, just vanilla fresh new
> W10 64bit Home preinstalled on HP Notebook
> German Language
> Version 1709
> Build system 16299.547
Hmmm. That should update itself to 1803 almost the same second you let
it anywhere near a network.
Anyway, the only time I've seen s
Am 14.07.2018 um 16:50 schrieb Achim Gratz:
Marco Atzeri writes:
currently I have over 7300 always busy
73C5-73C51000 /cygdrive/c/Windows/SysWOW64/cryptbase.dll
What type of Windows do you use? I have Home N for testing at home and
Server 2016 plus a bunch of users w/ Enterprise clien
Marco Atzeri writes:
> currently I have over 7300 always busy
> 73C5-73C51000 /cygdrive/c/Windows/SysWOW64/cryptbase.dll
What type of Windows do you use? I have Home N for testing at home and
Server 2016 plus a bunch of users w/ Enterprise clients (will get one
myself in a few days) and n
Am 12.07.2018 um 15:38 schrieb Corinna Vinschen:
On Jul 12 12:31, marco atzeri wrote:
from my experiments the 32bit under W10 is substantially unusable.
At every restart the base address of the wow64*.dll are moved
randomly everywhere between 0x5000 and 0x7000.
Actually, as I wrote
On Jul 12 12:31, marco atzeri wrote:
> On Tue, Jul 10, 2018 at 7:33 AM, Marco Atzeri wrote:
> > Am 09.07.2018 um 14:37 schrieb Corinna Vinschen:
> >
> >
> > It seems there is some type of ASLR for the wow64.
> > I will try to rebase using 0x6b00 to see if
> > make any change
> >
>
> from my e
On Tue, Jul 10, 2018 at 7:33 AM, Marco Atzeri wrote:
> Am 09.07.2018 um 14:37 schrieb Corinna Vinschen:
>
>
> It seems there is some type of ASLR for the wow64.
> I will try to rebase using 0x6b00 to see if
> make any change
>
from my experiments the 32bit under W10 is substantially unusable.
Am 09.07.2018 um 14:37 schrieb Corinna Vinschen:
It is like they put the 64bit System 32 over 0x6b00 (maybe)
0x6b00? In your previous mail you wrote 0x6f00.
I used 0x6f00 for my last rebase experiment as wow64 was
loading over there consistently.
Anyway I found another craz
On Jul 9 13:37, Marco Atzeri wrote:
> Am 7/9/2018 um 11:03 AM schrieb Corinna Vinschen:
> > On Jul 8 18:03, Marco Atzeri wrote:
> > > Am 30.06.2018 um 22:47 schrieb Ken Brown:
> > > > On 6/30/2018 11:52 AM, Marco Atzeri wrote:
> > > >
> > > > I've never had this problem with my own 32bit install
Am 7/9/2018 um 11:03 AM schrieb Corinna Vinschen:
On Jul 8 18:03, Marco Atzeri wrote:
Am 30.06.2018 um 22:47 schrieb Ken Brown:
On 6/30/2018 11:52 AM, Marco Atzeri wrote:
I've never had this problem with my own 32bit installation on W10, but I
just reproduced it by doing a new installation wi
On Jul 8 18:03, Marco Atzeri wrote:
> Am 30.06.2018 um 22:47 schrieb Ken Brown:
> > On 6/30/2018 11:52 AM, Marco Atzeri wrote:
> >
> > I've never had this problem with my own 32bit installation on W10, but I
> > just reproduced it by doing a new installation with your list of
> > packages. Have
Am 30.06.2018 um 22:47 schrieb Ken Brown:
On 6/30/2018 11:52 AM, Marco Atzeri wrote:
I've never had this problem with my own 32bit installation on W10, but I
just reproduced it by doing a new installation with your list of
packages. Have you tried just installing a minimal list of packages
t
Am 30.06.2018 um 22:47 schrieb Ken Brown:
On 6/30/2018 11:52 AM, Marco Atzeri wrote:
Hi,
on a new W10 HP Laptop, the 32 bit installation always fails
on postinstallation scripts that use perl.
The outcome is like:
$ ./texlive-collection-formatsextra.sh
1 [main] perl 1796 child_info_fork
On 6/30/2018 11:52 AM, Marco Atzeri wrote:
Hi,
on a new W10 HP Laptop, the 32 bit installation always fails
on postinstallation scripts that use perl.
The outcome is like:
$ ./texlive-collection-formatsextra.sh
1 [main] perl 1796 child_info_fork::abort: address space needed
by 'Encode.d
Marco Atzeri writes:
> on a new W10 HP Laptop, the 32 bit installation always fails
> on postinstallation scripts that use perl.
Please check if that installation has activated the option of forcing
ASLR on everything (even if explicitly marked non-ASRL aware).
> It is not due to an Antivirus as
On 2018-06-30 09:52, Marco Atzeri wrote:
> Hi,
> on a new W10 HP Laptop, the 32 bit installation always fails
> on postinstallation scripts that use perl.
>
> The outcome is like:
>
> $ ./texlive-collection-formatsextra.sh
> 1 [main] perl 1796 child_info_fork::abort: address space needed by
23 matches
Mail list logo
