If your main objective is to "copy" the File into ReactOS, then the best option is to "Mount" the Virtual HardDisk of your VirtualMachine. Mounting will let you place the file inside ReactOS without issues and from your host OS.Then when booting ReactOS you will see the file inside "magically".
If your main objective is to test the MM and overall ReactOS behavior in Vmware then thanks a lot, because your help could be really really helpful. :)
I've to say that lately ReactOS has improved a lot its stability under Vbox but seems it didn't do the same under Vmware as your tests shows.
It would be really nice if you can share which is your Virtual Machine configuration(Ram, HDD, etc) so maybe we can try to replicate the issue to find something useful in the logs.
Assertion 'InternalInfo' failed at /srv/buildbot_cmake/full_cmake/build/ntoskrnl/fsrtl/filelock.c line 857
Entered debugger on embedded INT3 at 0x0008:0x80924c32.
<NTOSKRNL.EXE:124c33 (/srv/buildbot_cmake/full_cmake/build/lib/rtl/i386/debug_asm.S:35 (_DbgBreakPoint@0))>
<NTOSKRNL.EXE:476cd (ReactOS/ntoskrnl/fsrtl/filelock.c:857 (FsRtlFastUnlockSingle@32))>
<NTOSKRNL.EXE:474b8 (ReactOS/ntoskrnl/fsrtl/filelock.c:1194 (FsRtlProcessFileLock@12))>
<NTOSKRNL.EXE:6343b (ReactOS/ntoskrnl/io/iomgr/iofunc.c:135 (IopPerformSynchronousRequest@28))>
<NTOSKRNL.EXE:110637 (ReactOS/ntoskrnl/ke/i386/traphdlr.c:1624 (@KiSystemServiceHandler@8))>
<NTOSKRNL.EXE:10dfd3 (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/ke/i386/trap.s:142 (_KiSystemService))>
If this didnt happen in 0.3.14 then we are in front of a regression. Nice catch!
We can try to find the guilty commit via Binary Search.
> Date: Wed, 19 Sep 2012 15:27:48 +0200
> From: michael.lackner@unileoben.ac.at
> To: ros-general@reactos.org
> Subject: Re: [ros-general] ReactOS BSOD / Freeze on large data transfers (and CPU load?)
>
> Hello!
>
> Thank you for your reply, I wasn't actually aware of those builds. I tried
> build #57337 (while I am writing this, it seems that 57338 is being released),
> but it went from bad to worse.
>
> While the transfer seemed to work longer than before (could be wrong about that
> though, not enough statistical data), it still ended with NTOSKRNL.EXE crashing.
>
> *** STOP: 0x0000001E (0xC000046, 0x808847C7, 0xF83495A8, 0x00000000)
> *** NTOSKRNL.EXE - Address 808847C7 base at 80800000
>
> On top of that, trying to start Filezilla 3.5.3 now results in another BSOD of
> NTOSKRNL.EXE (also 0x0000001E), which did not happen in 0.3.14.
>
> Additionally, that build boots into a BSOD on VMware Player 4.0.1, but boots up
> fine on VirtualBox 4.2, but that could easily be a fault of my configuration, as
> I'm not currently using the settings from the 0.3.14 VM images, but fresh ones,
> as this is a different host machine now.
>
> It kind of looks like I'm not going to get my preferred software to work in a
> stable fashion on ReactOS, at least when virtualized..
>
> I guess there is nothing I can do but to try new ReactOS builds every now and
> then?
>
> Thanks anyway!
>
> Aleksey Bragin wrote:
> > Hello!
> >
> > Could you try latest build from here http://www.reactos.org/getbuilds/ ?
> > It contains a number of networking improvements, however as for general
> > stability with regards to kernel crashes, the kernel memory manager is
> > still work in progress, so it may crash as easy as 0.3.14. But it would
> > be great to see whether the situation imprpved.
> >
> > If there is anything I can help with - let me know.
> >
> > Best regards,
> > Aleksey Bragin.
> >
> > On 17.09.2012 11:19, Michael Lackner wrote:
> >> Greetings!
> >>
> >> I would like to ask a question, maybe there is already an easy fix for this
> >> that I just cannot find using Google.
> >>
> >> So, I have set up ReactOS in both VirtualBox and VMware Player (4.0 & 5.0).
> >>
> >> What I am trying to do is to download a large ~700MB file using ftp.exe or
> >> Filezilla 2. Alternatively, I also tried to copy it from an ISO CD image.
> >>
> >> This never succeeds however. Either the machine just freezes or BSODs,
> >> according to bt it's something like "can't access memory at <some address>",
> >> with the error caused by the application doing the transfer.
> >>
> >> Mostly it just freezes though, especially when copying from CD ISO.
> >>
> >> So what I did then was to boot Knoppix and copy the file to ReactOS's
> >> partition offline. It's actually a video stream file. When I then tried to
> >> run my actual test (x264 video transcode), it works for a few minutes, then
> >> NTOSKRNL.EXE BSODs again, I didn't do a backtrace for that crash yet.
> >>
> >> Am I doing something specifically wrong to cause so many Kernel crashes, or
> >> is this still "normal" in 0.3.14? I mean: Is it normal to have the Kernel
> >> crash like that when just downloading or copying some files?!
> >>
> >> Thanks for any help you might be able to provide!
>
> --
> Michael Lackner
> Lehrstuhl für Informationstechnologie (CiT)
> Montanuniversität Leoben
> Tel.: +43 (0)3842/402-1505 | Mail: michael.lackner@unileoben.ac.at
> Fax.: +43 (0)3842/402-1502 | Web: http://institute.unileoben.ac.at/infotech
>
> _______________________________________________
> Ros-general mailing list
> Ros-general@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-general