From: Bob W. <bwh...@my...> - 2012-01-07 19:55:13
|
Hi Henry N.: >>> Bob Wheater wrote: >>> I have been having problems with blue screen crashes when running colinux. Vincent Rivière wrote: >>Vincent Rivière wrote: >> Adding /nopae in C:\boot.ini definitely solved the problem. Added /nopae: multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /NoExecute=OptIn/NoPAE /bootlog But, it did a blue screen crash again so does not work for this case. PAE applies to greater 4gb memory but my system is only 1gb. >But this bug is very difficult to find, because the >memory corruption was detected outside of coLinux. It >would help more, if you would have a stack trace with >module "linux" inside. >Henry N. I checked my 15 crash dumps and none of them have linux in the STACK TEXT section. Can you suggest what I can do to capture the stack information that you need to help you solve this crash problem. The problem is currently holding up the next release of Portable Ubuntu. Thanks. Regards, Bob Wheater |
From: Bob W. <bwh...@my...> - 2012-01-09 20:04:25
|
> Vincent Rivière wrote: >My complete boot.ini line is: >multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft >Windows XP Professionnel" /fastdetect >/noexecute=alwaysoff /nopae >To check if PAE is actually on or off, look at the >system properties (Win+Pause), on the General tab (the >default one). Look at the bottom, after the line with >frequency and amount of RAM. If "Physical Address >Extension" >is written, then PAE is on. If there is no such text, >PAE is off. >So please change your boot.ini to /noexecute=alwaysoff >/nopae then check it is actually disabled and see if >coLinux works better. My general tab on the system properties does NOT have Physical Address Extension. You seem to be confusing PAE with DEP (Data Execution Prevention). See http://technet.microsoft.com/en-us/library/cc738483%28WS.10%29.aspx The /noexecute switch controls DEP. However DEP may only apply to windows server 2003 and not XP. The PAE mode kernel requires an Intel Architecture processor, Pentium Pro or later, more than 4 GB of RAM, and Windows 2000, Windows XP, or Windows Server 2003. From: http://msdn.microsoft.com/en-us/windows/hardware/gg487503 According to this PAE does NOT apply to a 1gb system. It only applies to 4gb and greater systems. Regards, Bob |
From: Miller, S. <sha...@yr...> - 2012-01-09 20:15:38
|
Did you get my last message regarding possibly useful info you could share? If not, I'd appreciate it if you could review it. There are several kernels: * Uniprocessor, no-PAE (the default ntoskrnl.exe) * Uniprocessor, PAE (ntkrnlpa.exe) * Multiprocessor, no-PAE (ntkrnlmp.exe) * Multiprocessor, PAE (ntkrpamp.exe) Try using Microsoft's SysInternals' Process Explorer (ProcExp.exe), highlight the System process, then choose View -> Lower Pane View -> DLLs and make sure that View -> Show Lower Pane has a check-mark. Then scroll through the list of DLLs and observe which one matches the pattern ntXXX.exe. You can be using a PAE kernel without knowing it and without the /PAE switch in BOOT.INI. - Shao Miller ________________________________ From: Bob Wheater [mailto:bwh...@my...] Sent: Monday, January 09, 2012 15:04 To: col...@li... Subject: Re: [coLinux-users] Colinux Blue Screen Crashes > Vincent Rivière wrote: >My complete boot.ini line is: >multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft >Windows XP Professionnel" /fastdetect >/noexecute=alwaysoff /nopae >To check if PAE is actually on or off, look at the >system properties (Win+Pause), on the General tab (the >default one). Look at the bottom, after the line with >frequency and amount of RAM. If "Physical Address >Extension" >is written, then PAE is on. If there is no such text, >PAE is off. >So please change your boot.ini to /noexecute=alwaysoff >/nopae then check it is actually disabled and see if >coLinux works better. My general tab on the system properties does NOT have "Physical Address Extension". You seem to be confusing PAE with DEP (Data Execution Prevention). See http://technet.microsoft.com/en-us/library/cc738483%28WS.10%29.aspx The /noexecute switch controls DEP. However DEP may only apply to windows server 2003 and not XP. " The PAE mode kernel requires an Intel Architecture processor, Pentium Pro or later, more than 4 GB of RAM, and Windows 2000, Windows XP, or Windows Server 2003." From: http://msdn.microsoft.com/en-us/windows/hardware/gg487503 According to this PAE does NOT apply to a 1gb system. It only applies to 4gb and greater systems. Regards, Bob |
From: Bob W. <bwh...@my...> - 2012-01-09 21:11:35
|
Its using the default uniprocess kernel (nopae): ntoskrnl.exe NT Kernel & System Microsoft Corporation 5.1.2600.6165 according to process explorer. What last message? I though everything was posted to the list. I checked my files and the only message from you concerns posting the top part of windbg output which I did post when I reported the problem to the bug tracker. -Bob From: Miller, Shao [mailto:sha...@yr...] Sent: Monday, January 09, 2012 3:14 PM To: Bob Wheater Cc: col...@li... Subject: RE: [coLinux-users] Colinux Blue Screen Crashes Did you get my last message regarding possibly useful info you could share? If not, I'd appreciate it if you could review it. There are several kernels: * Uniprocessor, no-PAE (the default ntoskrnl.exe) * Uniprocessor, PAE (ntkrnlpa.exe) * Multiprocessor, no-PAE (ntkrnlmp.exe) * Multiprocessor, PAE (ntkrpamp.exe) Try using Microsoft's SysInternals' Process Explorer (ProcExp.exe), highlight the System process, then choose View -> Lower Pane View -> DLLs and make sure that View -> Show Lower Pane has a check-mark. Then scroll through the list of DLLs and observe which one matches the pattern ntXXX.exe. You can be using a PAE kernel without knowing it and without the /PAE switch in BOOT.INI. - Shao Miller |
From: Vincent R. <vin...@fr...> - 2012-01-09 21:31:52
|
Bob Wheater wrote: > You seem to be confusing PAE with DEP (Data Execution Prevention). From the page you quoted: http://msdn.microsoft.com/en-us/windows/hardware/gg487503 "The PAE kernel can be enabled automatically without the /PAE switch present in the boot entry if the system has DEP enabled (/NOEXECUTE switch is present) or the system processor supports hardware-enforced DEP. Presence of the /NOEXECUTE switch on a system with a processor that supports hardware-enforced DEP implies the /PAE switch. If the system processor is capable of hardware-enforced DEP and the /NOEXECUTE switch is not present in the boot entry, Windows assumes /NOEXECUTE=optin by default and enables PAE mode." > According to this PAE does NOT apply to a 1gb system. It only applies to 4gb > and greater systems. On my unhacked Windows XP SP3 virtual machine with 128 MB of RAM, PAE is enabled by default. Since Windows XP SP2, PAE is enabled by default on processors supporting hardware DEP. -- Vincent Rivière |
From: Bob W. <bwh...@my...> - 2012-01-22 20:44:38
|
>Henry N. Wrote on 1/7/12: >What you can do is to check that the ndis-driver is >truly the problem. >If you installs WinPcap and changes the coLinux config >from ndis-bridge into pcap-bridge. Disappears this the >problem? I have tried WinPCap and Slirp, both crash with memory corruption. >An other candidate for memory leakages is the option >"setcobd=async". It also crashes without this? Yes it crashes. >Can you give a command example for console to force >this bug on other distributions? For example running >"netio" under Debian 6.0 Squeeze It tried netio under Debian and it only runs for 4 or 5 minutes and does not use much additional memory. Since the crash occurs at memory utilization above 95% and this only got to 80% there was no crash. Can you suggest another console program that can be run continuously to use up enough memory to get above 95%. >I see, that you have only 384 MB for the virtual >machine. Comes the crash faster, if you use less memory >(for example 256)? Maybe it is a generally problem with >memory. I tried 256 and it crashed in about the same amount of time. The results of all these tests were reported in the bug tracker as comments. These things that you have asked me to try seem like a waste of time so far. It would be better if somebody that understands colinux well looked at the patterns in memory where the corruption is detected to see if they recognize anything related to what colinux is doing. Regards, Bob W. |
From: mawcowboy <vw...@bi...> - 2012-01-25 13:28:22
|
Hi Bob, Just another idea. My Computer --> System Properties --> Advanced --> Startup and Recovery - Settings --> Write debugging information --> Small memory dump then download http://www.nirsoft.net/utils/blue_screen_view.html What drivers does this utility indicate is at fault? Regards, Mark ----- Hi Bob, Not sure what to do here for you. I feel I should point out that I googled 3,000 hits with the search string "nt!KiFastCallEntry+0xf8 nt!KiTrap0E+0x233 ", This seems most likely a windows driver problem. If I add "colinux" to my search only your messages are found. I would continue investigation with the likely causes of "nt!KiFastCallEntry+0xf8 nt!KiTrap0E+0x233". Here is a tool that will show you what drivers are active on your system, http://www.nirsoft.net/utils/driverview.html This information may help. Regards, Mark Washburn ------------ -- View this message in context: http://old.nabble.com/Colinux-blue-screen-crashes-tp33076511p33191688.html Sent from the colinux-users mailing list archive at Nabble.com. |
From: Henry N. <hen...@ar...> - 2012-01-07 21:21:01
|
Hello Bob, Bob Wheater wrote: > Henry N. wrote: >> But this bug is very difficult to find, because the memory corruption >> was detected outside of coLinux. It would help more, if you would >> have a stack trace with module "linux" inside. >> >> Henry N. > > I checked my 15 crash dumps and none of them have “linux” in the STACK > TEXT section. Can you suggest what I can do to capture the stack > information that you need to help you solve this crash problem. The > problem is currently holding up the next release of Portable Ubuntu. > Thanks. > > Regards, > > Bob Wheater > No, you can nothing do with the dump or debugger. Assumed, coLinux ndis-driver will corrupt the memory of an other process, then very different task will see this, if they use the memory later. What you can do is to check that the ndis-driver is truly the problem. If you installs WinPcap and changes the coLinux config from ndis-bridge into pcap-bridge. Disappears this the problem? An other candidate for memory leakages is the option "setcobd=async". It also crashes without this? Can you give a command example for console to force this bug on other distributions? For example running "netio" under Debian 6.0 Squeeze I see, that you have only 384 MB for the virtual machine. Comes the crash faster, if you use less memory (for example 256)? Maybe it is a generally problem with memory. -- Henry N. |
From: Vincent R. <vin...@fr...> - 2012-01-08 19:14:14
|
Bob Wheater wrote: > Added /nopae:” multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft > Windows XP Professional" /fastdetect /NoExecute=OptIn/NoPAE /bootlog” > > But, it did a blue screen crash again – so does not work for this case. PAE > applies to greater 4gb memory but my system is only 1gb. Sure, PAE is useful only for systems with more than 3 (or 4?) GB of RAM, but since Windows XP SP2 (?) it is enabled by default, whatever amount of RAM you have. Now I remember that /nopae also requires to disable DEP with the switch /noexecute=alwaysoff otherwise it is still enabled. Also (not sure if it is important) be sure to insert a space before /NoPAE in your boot.ini. My complete boot.ini line is: multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professionnel" /fastdetect /noexecute=alwaysoff /nopae To check if PAE is actually on or off, look at the system properties (Win+Pause), on the General tab (the default one). Look at the bottom, after the line with frequency and amount of RAM. If "Physical Address Extension" is written, then PAE is on. If there is no such text, PAE is off. So please change your boot.ini to /noexecute=alwaysoff /nopae then check it is actually disabled and see if coLinux works better. -- Vincent Rivière |