VM Loaded?

> Hi Dave,
>
> Thanks! The particular error here is a failure to initialize a png plugin.
> We are definitely in the command line.  I would imagine a delay to allow
> the virus checker to finish would fix this problem but it would be better
> to know if we can proceed if that is even possible.  Notice the
> LdrResolveDelayLoadsFromDll maybe error handling at this point would work
> if it fails the problem may be scanning?
>
>
> Exception code: C0000005
> Exception addr: 6117E9C0
> Access violation (read access) at 7E31C014
> EAX:7E31C014    EBX:00000000    ECX:00000014    EDX:0000000E
> ESI:0002C014    EDI:0094D47C    EBP:0094D40C    ESP:0094D3C0
> EIP:6117E9C0    EFL:00010206
> FP Control: 0000027F
> FP Status:  00004022
> FP Tag:     0000FFFF
>
> Crashed in the VM thread
>
> Stack backtrace:
>         [6117E9C0] ??? + 0 in (null)
>         [6117F0F4] ??? + 0 in (null)
>         [6117F8D2] ??? + 0 in (null)
>         [6118024D] ??? + 0 in (null)
>         [61181DA4] ??? + 0 in (null)
>         [77779FCF] LdrUnregisterDllNotification + 2127 in ntdll.dll
>         [77769E4E] LdrParentRtlResetNtUserPfn + 2062 in ntdll.dll
>         [77781D7A] LdrResolveDelayLoadsFromDll + 1418 in ntdll.dll
>         [777635EB] RtlDosSearchPath_U + 683 in ntdll.dll
>         [7776D25F] LdrShutdownProcess + 1167 in ntdll.dll
>         [77777279] RtlGetAce + 3641 in ntdll.dll
>         [7777AEEB] RtlConsoleMultiByteToUnicodeN + 2763 in ntdll.dll
>         [7777B1B3] LdrParentRtlRetrieveNtUserPfn + 147 in ntdll.dll
>         [6117E6E2] ??? + 0 in (null)
>         [6118907C] ??? + 0 in (null)
>         [00A71000] ??? + 0 in (null)
>         [75E5AB86] LoadLibraryW + 38 in kernelbase.dll
>         [75E5A9C2] LoadLibraryExW + 50 in kernelbase.dll
>         [0043BCC1] ??? + 244929 in Terf.exe
>         [0043BD0A] ??? + 245002 in Terf.exe
>         [004470D5] ??? + 291029 in Terf.exe
>         [00447212] ??? + 291346 in Terf.exe
>         [00447429] ??? + 291881 in Terf.exe
>         [0040D8F1] ??? + 55537 in Terf.exe
>         [0041E94D] ??? + 125261 in Terf.exe
>         [0042373C] ??? + 145212 in Terf.exe
>         [00423C14] ??? + 146452 in Terf.exe
>         [0043E2F5] ??? + 254709 in Terf.exe
>         [0043E603] ??? + 255491 in Terf.exe
>         [00521C0D] ??? + 1186829 in Terf.exe
>         [004010BB] ??? + 4283 in Terf.exe
>         [004012C8] ??? + 4808 in Terf.exe
>         [77620419] AcquireSRWLockExclusive + 25 in kernel32.dll
>         [7779662D] RtlGetCompressionWorkSpaceSize + 237 in ntdll.dll
>         [777965FD] RtlGetCompressionWorkSpaceSize + 189 in ntdll.dll
>
> Primitive trace:
> findFirstInString:inSet:startingAt:
> primOpen:writable:
> shallowCopy
> primitiveWait
> basicNew
> new:
> at:put:
> at:put:
> signal
> basicNew:
> species
> basicNew:
> basicNew
> ensure:
> valueNoContextSwitch
> basicNew:
> size
> basicNew:
> replaceFrom:to:with:startingAt:
> size
> primRead:into:startingAt:count:
> at:
> shallowCopy
> basicNew
> new:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> at:put:
> shallowCopy
> new:
> replaceFrom:to:with:startingAt:
> at:put:
> value:
> on:do:
> value
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> -
> +
> basicNew:
> value:
> on:do:
> value
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> value:
> on:do:
> value
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> basicNew:
> size
> basicNew:
> size
> replaceFrom:to:with:startingAt:
> at:
> primGetPosition:
> basicNew:
> at:put:
> at:put:
> at:put:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> replaceFrom:to:with:startingAt:
> basicNew
> findNextHandlerContextStarting
> tempAt:
> tempAt:
> tempAt:put:
> ensure:
> valueNoContextSwitch
> tempAt:
> valueWithArguments:
> findNextUnwindContextUpTo:
> tempAt:
> tempAt:put:
> tempAt:
> terminateTo:
> value
> tempAt:put:
> findNextUnwindContextUpTo:
> terminateTo:
> value:
> on:do:
> value
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> basicNew:
> replaceFrom:to:with:startingAt:
> primJPEGPluginIsPresent
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> value:
> on:do:
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> primJPEGPluginIsPresent
> value:
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> primSize:
> species
> basicNew:
> size
> replaceFrom:to:with:startingAt:
> =
> species
> basicNew:
> -
> +
> replaceFrom:to:with:startingAt:
> +
> =
> bitShift:
> at:
> bitOr:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> bitShiftMagnitude:
> bitOr:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> bitShiftMagnitude:
> bitOr:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> bitShiftMagnitude:
> bitOr:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> bitShiftMagnitude:
> bitOr:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> species
> basicNew:
> replaceFrom:to:with:startingAt:
> bitShiftMagnitude:
> bitOr:
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> =
> basicNew
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> basicNew
> basicNew:
> decompress:fromByteArray:at:
> beCursorWithMask:
> ensure:
> size
> basicNew:
> size
> replaceFrom:to:with:startingAt:
> -
> +
> at:
> at:put:
> at:put:
> at:put:
> at:put:
> basicNew:
> at:put:
> basicNew
> basicSize
> basicNew
> @
> @
> basicNew
> basicNew
> basicSize
> copyBits
> basicNew
> basicNew
> new:
> basicNew
> new:
> primSizeNoError:
> primSizeNoError:
> primGetPosition:
> basicNew:
> +
> <
> pngPluginVersion
>
>
>
> Smalltalk stack dump:
>   0x950168 I PNGReadWriter>nextImage 295516516: a(n) PNGReadWriter
>   0x950188 M [] in ImageReadWriter class>formFromStream: 273588992: a(n)
> ImageReadWriter class
>   0x9501a8 M BlockClosure>ensure: 295516628: a(n) BlockClosure
>   0x9501d0 I CursorWithMask(Cursor)>showWhile: 273290060: a(n)
> CursorWithMask
>   0x950200 I ImageReadWriter class>formFromStream: 273588992: a(n)
> ImageReadWriter class
>   0x950228 I Form class>fromBinaryStream: 273599436: a(n) Form class
>   0x950250 M [] in QForms>import:from: 295487508: a(n) QForms
>   0x950270 M BlockClosure>ensure: 295506324: a(n) BlockClosure
>   0x9502a4 I [] in QForms>import:from: 295487508: a(n) QForms
>   0x9502c0 M BlockClosure>on:do: 295501124: a(n) BlockClosure
>   0x9502f8 I QForms>import:from: 295487508: a(n) QForms
>   0x950324 I QForms>initialize 295487508: a(n) QForms
>
>
> On Thu, Apr 11, 2019, 11:09 PM David T. Lewis <[hidden email]> wrote:
>
> > On Thu, Apr 11, 2019 at 04:20:10PM -0400, Ron Teitelbaum wrote:
> > >
> > > Hi All,
> > >
> > > When processing the command line I ran into an interesting problem.  When
> > > running normally everything processes fine but if I'm also running
> > Immunet
> > > which is scanning the VM for viruses as it starts up a quick command line
> > > can run into something that is not properly loaded and crash.  If I shut
> > > down the virus protection it runs fine, if I start the application first
> > > and then process the command line it runs fine.
> > >
> > > Is there something I can check in the image to know that the image is
> > fully
> > > loaded before processing the command line arguments?
> > >
> >
> > Hi Ron,
> >
> > I am more familiar with the Unix VMs, but I think that what I will say here
> > applies to any of the compiled VMs.
> >
> > When the VM and image are first started, the following things happen:
> >
> > - VM executable is loaded and begins execution. it is not yet in the
> >   interpreter, but is loaded and running.
> >
> > - Memory is allocated to contain the object memory.
> >
> > - Contents of the image file are read into the allocated memory.
> >
> > - The object memory is scanned, updating object pointers to match the
> >   position of the allocated memory
> >
> > - The interpreter loop is entered.
> >
> > - Smalltalk stuff happens, such as processing a command line.
> >
> > The object memory scan for fixing pointers seems key with respect to
> > the problem you are seeing, because it means that both the VM executable
> > and the object memory are fully load prior to Smalltalk execution, and
> > also that (in most cases) memory locations will have been written
> > throughout the object memory space.
> >
> > I am not entirely certain if the pointer fixups happen (or happen
> > always) on Windows, because the fixups are needed only if the memory
> > is loaded to a different virtual memory address than were in effect
> > when the image was last saved. Someone with better Windows experience
> > may be able to confirm or deny it.
> >
> > In any case, it seems likely that both the VM executable and the
> > complete object memory will have been fully loaded prior to executing
> > anything on a command line.
> >
> > The only other ideas I can think of are that 1) it might be somehow
> > related to jitted code, since the jit code generation kicks in after
> > Smalltalk is running, or 2) it might be somehow related to external
> > file or socket handles from the previous session, which are invalid
> > but possibly might confuse a virus scanner.
> >
> > I really can't guess what is going on here, but possibly the above
> > will prompt some better ideas from someone else.
> >
> > Dave
> >
> >
> >