Can not access PC

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I did an inplace upgrade with Vista, when it went into what I thought was the
final reboot it stops at a black screen with the build number in lower right
hand corner. It shows the arrow cursor and it is movable but ABSOLUTELY
NOTHING ELSE WORKS. I have tried to access my PC via, safe mode, got nothing,
via boot disk, doesn't see the c drive, via windows recovery console, asked
for a password and I guess I don't remember it cause it failed too. I know
when I started this the upgrade tool told me that all was ok except that my
video card didn't support the pixel shading or some s--- like that. Anyway I
am going to get a new video card but if that doesn't work as I see it I will
have to dump the drive reinstall xp and try again. Being as they didn't make
this a bootable disk. Is this the proper plan for me too follow or do you
have another idea?
 
The dvd image should boot when burned, does here so atleast.

If you want to try reporting the upgrade problem in more detail, you should
somehow get the *.log files from various places under the Vista Windows
directory and try submit these along with more detailed info of what was
installed on the computer (which antivirus and anti-malware progs etc) with
the Beta Client.
 
Hi,

Increment this problem counter by one.

I get exactly the same (non-)reaction as "MeSnowStalker", but from hard disk
clean install.

Also tried some variations, but to no avail.

Just black screen with build number and a moving mouse, but no reaction to
keyboard, no chance to log in, even in different protected start options.


Wolfram
 
Same here.. tried to install from XP and from a clean Hdd... just keep
getting a blank screen.. >_<
 
If you want to try sending bug report or try figure out the cause, here is
how to find the right logs:


1. google -> beta client
click the first link. It needs .NET but I think it will be installed if you
try to run it without it..

2. finding and identifying the correct logs

setupapi.app.log
setupapi.dev.log

These are the primary setup logs, there are others but these are the major.

A:

There can be multiple logs with the same name, but they are different! First
look at the drive you tried to install Vista to, if it has Vista
Windows\INF\ directory and under it:

B:

If you can't find Windows VISTA directory (if setup did not get so far) then
look all volumes/partitions in the drives that were on the machine during
the install for directories starting with $. There are 2-4 of them (possibly
in different partitions) depending on when the setup failed. Search for .log
under all the *:\$WINDOWS.. and again look at the date/minute timestamp to
see which of the logs was changed just before the failure occured.


See that the date and Minute timestamp of the log files are around the time
when the setup failed, sometimes a setup/install failure causes the computer
to automatically reboot and the setup will run again but failing in
different way than the first time (making the bug report less useful). For
best bug report it's better to catch the failure when it first happens. Yes
it means starting the install all over again and keeping eye on it. But this
will guarantee that the last line in the log will be around the time of the
failure. If it is a driver crash then you can figure out the offending
driver yourself just by looking at the last line of setupapi.dev.log.
 
droid said:
If you want to try sending bug report or try figure out the cause, here is
how to find the right logs:


1. google -> beta client
click the first link. It needs .NET but I think it will be installed if you
try to run it without it..

2. finding and identifying the correct logs

setupapi.app.log
setupapi.dev.log

These are the primary setup logs, there are others but these are the major.

A:

There can be multiple logs with the same name, but they are different! First
look at the drive you tried to install Vista to, if it has Vista
Windows\INF\ directory and under it:

B:

If you can't find Windows VISTA directory (if setup did not get so far) then
look all volumes/partitions in the drives that were on the machine during
the install for directories starting with $. There are 2-4 of them (possibly
in different partitions) depending on when the setup failed. Search for .log
under all the *:\$WINDOWS.. and again look at the date/minute timestamp to
see which of the logs was changed just before the failure occured.


See that the date and Minute timestamp of the log files are around the time
when the setup failed, sometimes a setup/install failure causes the computer
to automatically reboot and the setup will run again but failing in
different way than the first time (making the bug report less useful). For
best bug report it's better to catch the failure when it first happens. Yes
it means starting the install all over again and keeping eye on it. But this
will guarantee that the last line in the log will be around the time of the
failure. If it is a driver crash then you can figure out the offending
driver yourself just by looking at the last line of setupapi.dev.log.
Click to expand...


I get this problem some times...the way I resolve it is at the screen with
the build number at the bottom right where you can move your mouse, I hit
ctrl+alt+del then wait about a minute and it shows me the menu to log off or
bring up task manager etc. and I choose to log off, then I log back in and it
loads my desktop...not sure if this is the same thing you guys are getting.
 
Back
Top