> Can you help on what is the issue, and how I can solve it?
> If you need more info I'm available.
Ouch, that's not fun. I've never actually seen Python bsod by itself.
My first guesses are:
1) It's a buggy library that you're using with Python. Do you know
what modules your code calls on? Mainly ones that aren't part of the
standard library.
2) It's unrelated, but maybe triggered somehow. For instance, your
Python program might be consuming a lot of RAM, which causes a problem
when you make use of a faulty bit of memory somewhere in the higher
addresses.
Have you run a RAM test on that machine? This is a well-respected one:
http://www.memtest.org/
Alternatively, can you narrow the problem down to a particular script
that will repeatedly cause the BSOD?
> Can you help on what is the issue, and how I can solve it?
IMO, the easiest waht to avoid those is by not running Windows. ;)
Python is a user-space application. User-space applications can't
cause blue-screens unless they manage to trigger a bug in hardware, OS
kernel, or device driver.
The solution is usually to fix the hardware, OS, or device driver.
-- Grant Edwards grant.b.edwards Yow! I'm having an
at emotional outburst!!
gmail.com
On Fri, 21 Sep 2012 15:14:53 +0000, Grant Edwards wrote:
> On 2012-09-21, mikcec82 <michele.cec...@gmail.com> wrote:
>> Hallo to all,
>> I'm using Python 2.7.3 with Windows 7 @ 64 bit and an Intel Core i3
>> -2350M CPU @2.30GHz 2.3GHz.
>> Sometimes, when I'm programming in Python on my screen compare this
> Python is a user-space application. User-space applications can't cause
> blue-screens unless they manage to trigger a bug in hardware, OS kernel,
> or device driver.
But Windows does not have any true concept of user-space (although it does make an almost convincing pretence) it has been hacked up from an operating system that's original security model was "Lock the door when you leave the office"
-- Watch all-night Donna Reed reruns until your mind resembles oatmeal.
On Fri, 21 Sep 2012 16:01:16 +0000, Alister wrote:
> On Fri, 21 Sep 2012 15:14:53 +0000, Grant Edwards wrote:
>> On 2012-09-21, mikcec82 <michele.cec...@gmail.com> wrote:
>>> Hallo to all,
>>> I'm using Python 2.7.3 with Windows 7 @ 64 bit and an Intel Core i3
>>> -2350M CPU @2.30GHz 2.3GHz.
>>> Sometimes, when I'm programming in Python on my screen compare this
>> Python is a user-space application. User-space applications can't
>> cause blue-screens unless they manage to trigger a bug in hardware, OS
>> kernel,
>> or device driver.
> But Windows does not have any true concept of user-space (although it
> does make an almost convincing pretence) it has been hacked up from an
> operating system that's original security model was "Lock the door when
> you leave the office"
on a slightly more helpful front try adding break points to your code to see what part is actually causing the crash
-- Whenever I feel like exercise, I lie down until the feeling passes.
> On Fri, 21 Sep 2012 15:14:53 +0000, Grant Edwards wrote:
>> On 2012-09-21, mikcec82 <michele.cec...@gmail.com> wrote:
>>> Hallo to all,
>>> I'm using Python 2.7.3 with Windows 7 @ 64 bit and an Intel Core i3
>>> -2350M CPU @2.30GHz 2.3GHz.
>>> Sometimes, when I'm programming in Python on my screen compare this
>> Python is a user-space application. User-space applications can't cause
>> blue-screens unless they manage to trigger a bug in hardware, OS kernel,
>> or device driver.
True. Too bad there are so many of those bugs.
> But Windows does not have any true concept of user-space (although it > does make an almost convincing pretence) it has been hacked up from an > operating system that's original security model was "Lock the door when > you leave the office"
That's not true at all. You're thinking of Windows 3, Windows 95, 98,
and ME, which were hacked on top of MSDOS. But Windows NT3.5, 4, 2000,
XP, Vista and Windows 7 have an entirely different bloodline.
NT 3.51 was actually very robust, but in 4.0 to gain better performance,
they apparently did some compromising in the video driver's isolation. And who knows what's happened since then.
On Fri, 21 Sep 2012 18:47:57 -0400, Dave Angel wrote:
> On 09/21/2012 12:01 PM, Alister wrote:
>> On Fri, 21 Sep 2012 15:14:53 +0000, Grant Edwards wrote:
>>> On 2012-09-21, mikcec82 <michele.cec...@gmail.com> wrote:
>>>> Hallo to all,
>>>> I'm using Python 2.7.3 with Windows 7 @ 64 bit and an Intel Core i3
>>>> -2350M CPU @2.30GHz 2.3GHz.
>>>> Sometimes, when I'm programming in Python on my screen compare this
>>> Python is a user-space application. User-space applications can't
>>> cause blue-screens unless they manage to trigger a bug in hardware, OS
>>> kernel,
>>> or device driver.
> True. Too bad there are so many of those bugs.
>> But Windows does not have any true concept of user-space (although it
>> does make an almost convincing pretence) it has been hacked up from an
>> operating system that's original security model was "Lock the door when
>> you leave the office"
> That's not true at all. You're thinking of Windows 3, Windows 95, 98,
> and ME, which were hacked on top of MSDOS. But Windows NT3.5, 4, 2000,
> XP, Vista and Windows 7 have an entirely different bloodline.
> NT 3.51 was actually very robust, but in 4.0 to gain better performance,
> they apparently did some compromising in the video driver's isolation.
> And who knows what's happened since then.
Although NT upwards has tried to introduce user-space requirements the need to maintain backwards compatibility has compromised these efforts.
it is not helped by the end user's (just look at what happened to Vista's attempt to make users authorise any changes to the system)
-- VMS, n.:
The world's foremost multi-user adventure game.
> On Fri, 21 Sep 2012 18:47:57 -0400, Dave Angel wrote:
>> <SNIP>
>> That's not true at all. You'd re thinking of Windows 3, Windows 95, 98,
>> and ME, which were hacked on top of MSDOS. But Windows NT3.5, 4, 2000,
>> XP, Vista and Windows 7 have an entirely different bloodline.
>> NT 3.51 was actually very robust, but in 4.0 to gain better performance,
>> they apparently did some compromising in the video driver's isolation.
>> And who knows what's happened since then.
> Although NT upwards has tried to introduce
Your wording seems to imply that you still think NT was built on some
earlier MS product. It was written from scratch by a team recruited
mostly from outside MS, including the leader, a guy who was I think
experienced in VMS development. The names escape me right now. But
there were a couple of books, by Helen someone, I think, which helped us
outsiders understand some of the philosophies of the development.
> user-space requirements the > need to maintain backwards compatibility has compromised these efforts.
> it is not helped by the end user's (just look at what happened to Vista's > attempt to make users authorise any changes to the system)
I don't see any connection between memory address space user models and
user security models.
> > On Fri, 21 Sep 2012 18:47:57 -0400, Dave Angel wrote:
> >> <SNIP>
> >> That's not true at all. You'd re thinking of Windows 3, Windows 95, 98,
> >> and ME, which were hacked on top of MSDOS. But Windows NT3.5, 4, 2000,
> >> XP, Vista and Windows 7 have an entirely different bloodline.
> >> NT 3.51 was actually very robust, but in 4.0 to gain better performance,
> >> they apparently did some compromising in the video driver's isolation.
> >> And who knows what's happened since then.
> > Although NT upwards has tried to introduce
> Your wording seems to imply that you still think NT was built on some
> earlier MS product. It was written from scratch by a team recruited
> mostly from outside MS, including the leader, a guy who was I think
> experienced in VMS development. The names escape me right now. But
> there were a couple of books, by Helen someone, I think, which helped us
> outsiders understand some of the philosophies of the development.
> > user-space requirements the
> > need to maintain backwards compatibility has compromised these efforts.
> > it is not helped by the end user's (just look at what happened to Vista's
> > attempt to make users authorise any changes to the system)
> I don't see any connection between memory address space user models and
> user security models.
> --
> DaveA
I tested MS NT in 1998-2002. I was pleased by the results to run real
multi-tasking processes at that time. I ran some linux machines at that time, too.
Anyway the heap walker problems in all the unix and linux systems
were very obvious in those years.
My conclusion at that time was people from DEC were really good in the OS.
> > On Fri, 21 Sep 2012 18:47:57 -0400, Dave Angel wrote:
> >> <SNIP>
> >> That's not true at all. You'd re thinking of Windows 3, Windows 95, 98,
> >> and ME, which were hacked on top of MSDOS. But Windows NT3.5, 4, 2000,
> >> XP, Vista and Windows 7 have an entirely different bloodline.
> >> NT 3.51 was actually very robust, but in 4.0 to gain better performance,
> >> they apparently did some compromising in the video driver's isolation.
> >> And who knows what's happened since then.
> > Although NT upwards has tried to introduce
> Your wording seems to imply that you still think NT was built on some
> earlier MS product. It was written from scratch by a team recruited
> mostly from outside MS, including the leader, a guy who was I think
> experienced in VMS development. The names escape me right now. But
> there were a couple of books, by Helen someone, I think, which helped us
> outsiders understand some of the philosophies of the development.
> > user-space requirements the
> > need to maintain backwards compatibility has compromised these efforts.
> > it is not helped by the end user's (just look at what happened to Vista's
> > attempt to make users authorise any changes to the system)
> I don't see any connection between memory address space user models and
> user security models.
> --
> DaveA
I tested MS NT in 1998-2002. I was pleased by the results to run real
multi-tasking processes at that time. I ran some linux machines at that time, too.
Anyway the heap walker problems in all the unix and linux systems
were very obvious in those years.
My conclusion at that time was people from DEC were really good in the OS.
> Your wording seems to imply that you still think NT was built on some
> earlier MS product. It was written from scratch by a team recruited
> mostly from outside MS, including the leader, a guy who was I think
> experienced in VMS development. The names escape me right now. But
> there were a couple of books, by Helen someone, I think, which helped us
> outsiders understand some of the philosophies of the development.
IIRC many of the people involved had VMS experience. Apparantly M$ decided they needed a team who knew something about designing and implementing operating systems :)
On Sat, 22 Sep 2012 07:44:24 -0400, Dave Angel wrote:
[...]
> Your wording seems to imply that you still think NT was built on some
> earlier MS product. It was written from scratch by a team recruited
> mostly from outside MS, including the leader, a guy who was I think
> experienced in VMS development.
I believe you are thinking of Dave Cutler, who wasn't just experienced in VMS development, he invented VMS. He also helped design the VAX, hated Unix with a passion, and killed off the RSTS operating system. He's now working on the Xbox.
Windows NT was one of the reasons the IBM and Microsoft fell out. IBM and Microsoft partnered to build a new generation operating system, OS/2. Microsoft blew through a whole lot of IBM's money, produced something that they called version 1 but was more like version 0.1 (it only did text applications and had no GUI). They did eventually bring out a 1.1 version with a GUI, a year later.
As per their partnership agreement, IBM took over development of OS/2 version 2 while Microsoft worked on developing version 3. OS/2 2.0 was significantly improved over the 1.x series.
Then Microsoft reneged on the agreement to release OS/2 version 3, and instead re-badged it as Windows NT. One might say there was a little bit of bad blood over this, especially as IBM had good reason to think that Microsoft had been spending IBM's money on NT.
<steve+comp.lang.pyt...@pearwood.info> wrote:
> As per their partnership agreement, IBM took over development of OS/2
> version 2 while Microsoft worked on developing version 3. OS/2 2.0 was
> significantly improved over the 1.x series.
> Then Microsoft reneged on the agreement to release OS/2 version 3, and
> instead re-badged it as Windows NT. One might say there was a little bit
> of bad blood over this, especially as IBM had good reason to think that
> Microsoft had been spending IBM's money on NT.
And ever since then, Microsoft's been doing its best to kill OS/2 off.
By the look of the database server sitting next to me, and the clients
scattered throughout the building, it seems they have yet to
succeed...
OS/2 and Linux interoperate quite happily, too. Standards FTW.
> > As per their partnership agreement, IBM took over development of OS/2
> > version 2 while Microsoft worked on developing version 3. OS/2 2.0 was
> > significantly improved over the 1.x series.
> > Then Microsoft reneged on the agreement to release OS/2 version 3, and
> > instead re-badged it as Windows NT. One might say there was a little bit
> > of bad blood over this, especially as IBM had good reason to think that
> > Microsoft had been spending IBM's money on NT.
> And ever since then, Microsoft's been doing its best to kill OS/2 off.
> By the look of the database server sitting next to me, and the clients
> scattered throughout the building, it seems they have yet to
> succeed...
> OS/2 and Linux interoperate quite happily, too. Standards so .
> ChrisA
This is off topic in this forum. But we are getting so far at the MMU part. A cpu with an L1 and an L2 caches of large sizes is better to be
equipped with a VMS like OS in the thread and the heap managements.
But if the situation is different, some other alternative approaches
might be more appropriate.
> > As per their partnership agreement, IBM took over development of OS/2
> > version 2 while Microsoft worked on developing version 3. OS/2 2.0 was
> > significantly improved over the 1.x series.
> > Then Microsoft reneged on the agreement to release OS/2 version 3, and
> > instead re-badged it as Windows NT. One might say there was a little bit
> > of bad blood over this, especially as IBM had good reason to think that
> > Microsoft had been spending IBM's money on NT.
> And ever since then, Microsoft's been doing its best to kill OS/2 off.
> By the look of the database server sitting next to me, and the clients
> scattered throughout the building, it seems they have yet to
> succeed...
> OS/2 and Linux interoperate quite happily, too. Standards so .
> ChrisA
This is off topic in this forum. But we are getting so far at the MMU part. A cpu with an L1 and an L2 caches of large sizes is better to be
equipped with a VMS like OS in the thread and the heap managements.
But if the situation is different, some other alternative approaches
might be more appropriate.
> In my script I open and close an html (in a FOR cycle); could be this the problem?
Unless you're running your Python script as a kernel driver (and you
can't do that accidentally), there is no way that your user-space
program should cause a bluescreen. This is an error in Windows (or one
of the drivers), not in Python or your program.
What you can do is insert your Windows DVD, boot from it, and click Repair.
> Or is it possible that Python 2.7 is not compatible with Win7?
No, even if a user-space program could legitimately cause a bluescreen,
Python 2.7 still works fine one thousands of Win7 machines.
> Can you help on what is the issue, and how I can solve it?
> If you need more info I'm available.
> Thank you so much,
> Michele
Thank you so much Philipp.
Now I am at work and I can't insert Windows DVD, but as soon as possible I'll done as you said and report you if the problem is solved or not.
