And this only happened in the binfs system. When I implemented the
RAMIMG for the whole NK.NB0, there is no such issue.
You have to add more modules in kernel section (NK). I mean more than those
that Microsoft said that must be included in NK section.
Of course, it depends on your image configuration:
I discover this when I try all module on NK section. After digging a bit I
found that those modules (for me) must be presents in NK section
It looks like a deadlock when filesys is closing all file system but needs
to access some module after!
Try this list. If it's not sufficient, try some more.
nk.exe
kernel.dll
coredll.dll
k.coredll.dll
gwes.dll
filesys.dll
romfsd.dll
device.dll
udevice.exe
devmgr.dll
busenum.dll
ceddk.dll
k.ceddk.dll
regenum.dll
pm.dll
exfat.dll
diskcache.dll
Fatutil.dll
k.fatutil.dll
fsdmgr.dll
mspart.dll
nanddiskXip.dll
nanddisk.dll
boot.hv
initdb.ini
binfs.dll
default.fdf
oalioctl.dll
fpcrt.dll
k.fpcrt.dll
CacheFilt.dll
; needed for PCMCIA"
giisr.dll
; to not block in suspend/resume
servicesEnum.dll
servicesd.exe
services.exe
servicesStart.exe
;
toolhelp.dll
oleaut32.dll
k.oleaut32.dll
ole32.dll
k.ole32.dll
winsock.dll
ws2.dll
iphlpapi.dll
k.iphlpapi.dll
wspm.dll
ceshell.dll
wininet.dll
shlwapi.dll
commctrl.dll
commdlg.dll
urlmon.dll
shdocvw.dll
shdoclc.dll
mlang.dll
ws2instl.dll
nspm.dll
ws2k.dll
ws2serv.dll
ssllsp.dll
schannel.dll
credsvc.dll
afd.dll
tcpstk.dll
lpcd.dll
lpcrt.dll
veim.dll
Regards
"lq1...@hotmail.com" <lq1231ho...@discussions.microsoft.com> wrote in
message news:9DEFC7F5-7A5C-4080...@microsoft.com...
After I put the followed four files into the RAMIMAGE region, it seems
the suspend/resume issue was fixed now.
servicesEnum.dll
servicesd.exe
services.exe
servicesStart.exe
Thanks for your help.