I wonder because running it on a client's minidump it reports a different Windows version than the client repeatedly told me she had, and the version I'm being reported happens to be exactly the same version I'm running WinDbg on.
So I wonder, can vertarget always be trusted (and clients not) or the information it relies on may be absent with some dump generation options and when it is it reports the version WinDbg is currently running on, or maybe just some default that happens to coincide with my OS version?
I'm using WinDbg 6.12.
In all my cases so far, vertarget has been correct and the customer/client made a mistake - and vertarget is one of the commands I use for every dump, exactly for the purpose of checking if the dump contains what I need.
But perhaps, things can potentially go wrong here as well, so let's evaluate some options:
vertarget also reports debug session time and system uptime. Do those also match your system? Reboot your system in order to get a low system uptime and check again. Is it still your PC's uptime?
vertarget also reports the number of CPUs. Does that number match your number?
Get a virtual machine which does not have your OS, e.g. one from Modern.IE (Microsoft). Copy WinDbg and the dump to the VM and check the output of vertarget again.
WinDbg 6.12 is a bit old. Do newer versions (6.2.9200 / 6.3.9600 or even 10.0) provide the same information or was there a bug fixed already?
And even check some other information:
Is it a dump of the correct application? Use | (pipe)
Is it a dump of the version you are expecting? Use lm vm <exename>
Does it have the flags which can be expected for the method used for taking the dump? Use .dumpdebug.
Other than that I observe (not representative) that many client OS version dumps (Windows 7, 8, 8.1) have all latest service packs installed, while administrators seem to follow the "never change a running system" approach for server OS (Windows Server 2012, R2). So it might just be a coincident.
Related
What would be the simplest and most portable way (in the sense of only having to copy a few files to the target machine, like procdump is) to generate a kernel dump that has handle information?
procdump has the -mk option which generates a limited dump file pertaining to the specified process. It is reported in WinDbg as:
Mini Kernel Dump File: Only registers and stack trace are available. Most of the commands I try (!handle, !process 0 0) fail to read the data.
Seems that officially, windbg and kd would generate dumps (which would require kernel debugging).
A weird solution I found is using livekd with -ml: Generate live dump using native support (Windows 8.1 and above only).. livekd still looks for kd.exe, but does not use it :) so I can trick it with an empty file, and does not require kernel debugging. Any idea how that works?
LiveKD uses the undocumented NtSystemDebugControl API to capture the memory dump. While you can easily find information about that API online the easiest thing to do is just use LiveKD.
I had to change the name of the windows 7 system. Unaccountably, vncserver is still using the old computer name. This was RealVnc free version. I re-installed but it is still using the old computer name.
I had a Z400 motherboard go bad and it took the disk drive. I replaced the motherboard, $39 was cheap, and I cloned one of my other Z400 workstation C drives using Acronis. I booted the replacement motherboard with the cloned copy, changed its name to the old defective one, and activated windows. When It rebooted, vncserver still had the old computer name and I cannot get rid of it and it is conflicting with the vncserver on the other Z400 since they both use the same name. There is no option in the server to use a different name that I can find anywhere.
IPs are different and all system behave fine. I can ping and even access shares using their names. The problem system clearly shows the correct name but, unaccountably, vncserver is using the wrong name.
This system will be upgraded to 10 in a few days, maybe the problem will go away when that happens.
Solved! First I had to log in and reduce the number of clients to under 5 as that was my limit. Then I had to remove the problem system's leftover name. This was all done at realvnc web site. Once under 5 systems then I could add the problem one and once it connected to realvnc's cloud then it got the correct name. This was an artifact of having more then 5 systems when I was only licensed for 5. The "6th" one worked locally as its setup was still valid, but it was refused connection to the cloud so it never got to change its name. It "worked" until I did a flushdns and its old setup was no longer valid.
We record our office IP phone activity using Xima software's Chronicall, which uses a PostgreSQL backend. The server on which both of these are installed is an ESXi 5.5 VM running Windows Server Standard 2008 SP1. For some time now, we have been getting the following PostgreSQL errors in Windows event viewer:
"FATAL: could not reattach to shared memory (key=248,
addr=02510000): 487"
"WARNING: worker took too long to start; cancelled"
These errors occur every hour or two, and always occur back-to-back in the order listed above.
Xima support has looked at the issue multiple times and has not been able to resolve it. Upon their recommendation, I have upgraded Java, disabled antivirus, and run the Windows Memory Diagnostic Tool (came back clean), but the errors persist. Xima has specifically stated that PostgreSQL should not be updated, as versions above 8.3.7 are known to cause other issues with Chronicall.
Any other suggestions to resolve this issue?
I would say the company (Xima) is at fault here, since PostgreSQL 8.3.7 is hopelessly outdated.
Quoting the official Versioning policy of Postgres:
Postgres 8.3 has reached EOL in Februar 2013
Moreover, Postgres strongly recommends:
We always recommend that all users run the latest available minor
release for whatever major version is in use.
The latest point release of 8.3 is 8.3.23.
Version 8.3.7 is just not right.
Running Postgres on a Windows Server 2008 VM wouldn't be my first idea either...
I'm setting up some new VNC servers. I already have this setup working with CentOS 6.3, although I'm not certain that this difference is the real problem.
One of the window managers I'm making available is fluxbox, but when I start it, I always get the following: Error: Couldn't connect to XServer. Here's my setup:
fluxbox: fluxbox-1.1.1-5.el6.x86_64
vnc : tigervnc-server-1.1.0-5.el6_4.1.x86_64
OS : CentOS 6.4
Note that I can start other window managers: Gnome, KDE, openbox, xfce4, etc.
I gutted my ~/.vnc/xstartup script so it only loads an xterm. Then, I tried running startfluxbox &, but still got the error. Obviously, VNC is working, since my xterm opened up OK. I can start firefox, another xterm or other app requiring X, and even fluxbox comes up, but it is worthless in its current state, since it is not connected to the X session.
What is fluxbox looking for? Are there some log files I can look at to give me some clues?
Thanks,
David
CentOS/RHEL 6.4 and up have upgraded libX11 and Xorg.
The $DISPLAY var handling has changed in libX11.
This one in particular is described in this git commit:
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=f92e754297ec5fdb81068b56a4435026666224fa
we run our fluxbox with this script in our vnc configs now:
/usr/bin/fluxbox -display "$DISPLAY.0"
OK, I think I've figured out the problem, so I'm answering my own question.
In VNC, I usually specify a display number. (Note, however, that the problem occurs even if vncserver uses the first available display number.) So, I start the vncserver as:
vncserver :17
This should create an X session where my $DISPLAY is set to :17.0, but in CentOS 6.4, the $DISPLAY is set to :17 instead. Apparently, unlike other window managers, fluxbox is unable to handle this inaccuracy. The problem, then, was that fluxbox was trying to connect to :17 and was unable to do so.
My solution, as suggested by someone answering a different problem, was to set $DISPLAY as part of the invocation of fluxbox. So, in my ~/.vnc/xstartup file, I have:
DISPLAY=$DISPLAY.0 startfluxbox &
Note that this may not work for other releases of CentOS, so you might wish to test the release of the box you are using before adding the DISPLAY=... setting to the command.
I have a fc14 32 bit system with 2.6.35.13 custom compiled kernel.
When I try to start G-wan I get a "Segmentation fault".I've made no changes, just downloaded and unpacked the files from g-wan site.
In the log file I have:
"[Wed Dec 26 16:39:04 2012 GMT] Available network interfaces (16)"
which is not true, on the machine i have around 1k interfaces mostly ppp interfaces.
I think the crash has something to do with detecting interfaces/ip addresses because in the log after the above line I have 16 lines with ip's belonging to the fc14 machine and after that about 1k lines with "0.0.0.0" or "random" ip addresses.
I ran gwan 3.3.7 64-bit on a fc16 with about the same number of interfaces and had no problem,well it still reported a wrong number of interfaces (16) but it did not crashed and in the log file i got only 16 lines with the ip addresses belonging to the fc16 machine.
Any ideas?
Thanks
I have around 1k interfaces mostly ppp interfaces
Only the first 16 will be listed as this information becomes irrelevant with more interfaces (the intent was to let users find why a listen attempt failed).
This is probably the long 1K list, many things have changed internally after the allocator was redesigned from scratch. Thank you for reporting the bug.
I also confirm the comment which says that the maintenance script crashes. Thanks for that.
Note that bandwidth shaping will be modified to avoid the newer Linux syscalls so the GLIBC 2.7 requirement will be waved.
...with a custom compiled kernel
As a general rule, check again on a standard system like Debian 6.x before asking a question: there is room enough for trouble with a known system - there's no need to add custom system components.
Thank you all for the tons(!) of emails received these two last days about the new release!
I had a similar "Segmentation fault" error; mine happens any time I go to 9+GB of RAM. Exact same machine at 8GB works fine, and 10GB doesn't even report an error, it just returns to the prompt.
Interesting behavior... Have you tried adjusting the amount of RAM to see what happens?
(running G-WAN 4.1.25 on Debian 6.x)