What WinDbg version is compatible with NT 4.0 (SP 6a) for kernel debug? - windbg

I'm working with WinDbg 6.12 with both serial port connection and named pipe connection. Unfortunately I'm unable to connect my WinDbg with the target (NT 4 SP 6a) from the begining of the OS boot, autoreconnect doesn't work and I need to wait until NT 4 timeout for kernel connection is reached. Then NT continues with the startup process and only then I can connect...
Where I can get a version fully compatible with NT 4? (I have already checked the oldest version from Microsoft Debugging Tools website)
Also, where can I get the NT 4 symbols for debugging? I'm afraid the Microsoft Symbols Server doesn't provide these symbols anymore.
Thanks,
For futher details, the kd log is:
Opened \\.\pipe\com_1
Waiting to reconnect...
Connected to Windows NT 4 1381 x86 compatible target at (Tue Jan 24 16:32:17.010 2012 (UTC + 1:00)), ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: srv*b:\out*o:\out*http://msdl.microsoft.com/download/symbols
Executable search path is:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntoskrnl.exe -
CS descriptor lookup failed
Windows NT 4 Kernel Version 1381 UP Free x86 compatible
Machine Name:
Kernel base = 0x80100000 PsLoadedModuleList = 0x80150b70
System Uptime: not available
The call to LoadLibrary(kdextx86) failed, Win32 error 0n2
"El sistema no puede hallar el archivo especificado."
Please check your debugger configuration and/or network access.
Unable to get program counter
WaitForEvent failed
Unable to get program counter
0008:497a 0010 add byte ptr [bx+si],dl
kd>

Works with http://msdl.microsoft.com/download/symbols/debuggers/dbg_amd64_6.7.05.1.exe
From Windbg 6.12 help:
"Windows NT 4.0
Debugging Tools for Windows no longer supports the debugging of Windows NT 4.0 targets.
If you want to debug a Windows NT 4.0 target computer or perform user-mode debugging on Windows NT 4.0, you should use Debugging Tools for Windows version 6.7.5.1. You can install this package from the Debugging Tools for Windows Web site."

Related

Can't flash CM0+ Core in NUCLEO STM32WL

In a wireless project, I'm using en Nucleo STM32WLJC1 in dual core configuration.
I take DualCore Ping Pong ST code example, that I rework to make my own application.
I didn't touch anything of the CMO+ project, I only work on the applicative layer in CM4.
I've some problems about flashing the CM0+ Core.
The first time I flashed the board it works and now I've most of the times the folowing error when I try to flash the CM0+. It sometimes work one time for no reason.
Pop-up Problem Occurred Windows :
Error in final launch sequence:
Failed to start GDB server Failed to start GDB server Error in
initializing ST-LINK device. Reason: (255) Unknown. Please check power
and cabling to target.
Console informations
STMicroelectronics ST-LINK GDB server. Version 6.0.0 Copyright (c)
2021, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistent Mode : Disabled
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
Target unknown error 32
Error in initializing ST-LINK device. Reason: Unknown. Please check
power and cabling to target.
It looks like the STlink can't reach the core...
Someone may know what is happening ?
Is there a flashing configuration that has to be done? (to chose which core we want to flash)

Getting WSO2 IOT Server running as a Windows Service

I have installed WSO2 IOT Server on Server 2012R2. I installed YAJSW wrapper and configured it per WSO2 instructions. When I fire off runConsole.bat to configure the Windows service, I get the following error. I have JAVA_HOME & CARBON_HOME set. It looks like the process cannot find files, but the directory exists and there are files files there.
c:\Program Files\yajsw\bat>call setenv.bat
"java" -Xmx30m -Djna_tmpdir="c:\Program Files\yajsw\bat\/../tmp" -Djava.net.pref
erIPv4Stack=true -jar "c:\Program Files\yajsw\bat\/../wrapper.jar" -c "c:\Progra
m Files\yajsw\bat\/../conf/wrapper.conf"
YAJSW: yajsw-stable-12.08
OS : Windows Server 2012 R2/6.3/amd64
JVM : Oracle Corporation/1.8.0_121/C:\Program Files\Java\jre1.8.0_121/64
Feb 23, 2017 8:09:07 AM org.apache.commons.vfs2.VfsLog info
INFO: Using "C:\Users\ADMINI~1.LEA\AppData\Local\Temp\1\vfs_cache" as temporary
files store.
WARNING|wrapper|"WSO2 Carbon"|17-02-23 08:09:07|YAJSW: yajsw-stable-12.08
WARNING|wrapper|"WSO2 Carbon"|17-02-23 08:09:07|OS : Windows Server 2012 R2/6.
3/amd64
WARNING|wrapper|"WSO2 Carbon"|17-02-23 08:09:07|JVM : Oracle Corporation/1.8.0_
121/C:\Program Files\Java\jre1.8.0_121/64
Feb 23, 2017 8:09:08 AM org.rzo.yajsw.wrapper.FileUtils getFiles
WARNING: No files found for C:\Program Files\WSO2\\bin\*.jar
system.env 55
INFO|wrapper|"WSO2 Carbon"|17-02-23 08:09:08|started process with pid 638044
INFO|wrapper|"WSO2 Carbon"|17-02-23 08:09:08|restart process due to default exit
code rule
INFO|wrapper|"WSO2 Carbon"|17-02-23 08:09:08|restart internal RUNNING
INFO|wrapper|"WSO2 Carbon"|17-02-23 08:09:08|stopping process with pid/timeout 6
38044 45000
INFO|wrapper|"WSO2 Carbon"|17-02-23 08:09:09|process exit code: 1
I had the same issue when I was using yajsw 12.08. And yajsw 11.11 has solved it.
Download link: https://sourceforge.net/projects/yajsw/files/yajsw/yajsw-stable-11.11/

Error launching openOCD debugger in Eclipse

I am setting up openOCD and Eclipse on a new operating system, using a Nucleo F030R8 board that debugs fine on another system. When I run the debugger in Eclipse I get "error in final launch sequence":
Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:3333
Error message from debugger back end:
localhost:3333: No such file or directory.
Failed to execute MI command:
-target-select remote localhost:3333
Error message from debugger back end:
localhost:3333: No such file or directory.
localhost:3333: No such file or directory.
I can run the debugger in terminal with ./openocd -f board/st_nucleo_f0.cfg and get:
*GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.9.0-00073-gdd34716
(2015-05-19-12:55)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results
might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v25 API v2 SWIM v13 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.257369
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints''*
and the LED LD1 blinks alternatively green and red. Similarly, I can run External Tools in Eclipse just fine, but this doesn't open the debugger. So it seems like I'm close, but something isn't quite right. Let me know if you need any other details of my system.
Using:
Eclipse Mars.2 (4.5.2)
Mac 10.12.1
OpenOCD 0.10.0-201601101000-dev
GNU Tools gcc-arm-none-eabi-5_4-2016q3
Ok so I figured it out with major credit due to http://www.carminenoviello.com. Running this in terminal:
>telnet localhost 3333
localhost: nodename nor servname provided, or not known
showed this wasn't working correctly. checking /etc/hosts, the file was empty. I changed it to:
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
And that was that. Can now enter debug mode.

visual basic 5 run-time error 429 dbengine.workspaces

I had an application perfectly working under Windows XP (32 bit). Moving to Windows 7 (64 bit) and compiling gives me the error run time error 429 ActiveX component can't create object in the module (second line, "set mydb=...", see code) where I make the connection with the MS Access database (Access 2013 in Windows 7 64 bit). In Windows XP it was an Access 2000 database with extension .mdb. Now it is Access 2013 with extension .accdb.
In the references I replaced the Microsoft Office DAO 3.5 library with the Microsoft Office 15.0 Access Database Engine Object Library, but this doesn't solve the problem. (If I leave the DAO object library, then I get run time error 3343 unrecognized database format on the same line.)
I'm not sure if I have to put in the components of the forms the 32 or the 64 bit version. (For example, dbrgid32.ocx under windows\system32 or under windows\sysWOW64 ... or does it not matter?)
Sub pldata()
Set mydb = DBEngine.Workspaces(0).OpenDatabase("D:\ETC\Gegevens\ETC2015.accdb", False, False, "MS Access")
'Set mydb = DBEngine.Workspaces(0).OpenDatabase("D:\ETC\Gegevens\ETC2015.accdb")ess")
Set myrstadres = mydb.OpenRecordset("select * from dbadres order by naam")
End Sub

mscorjit overlaps mscoree when using windbg

Loading Dump File [C:\Crash_Mode__Date_12-05-2009__Time_15-54-2727\PID-4056__CCNET.EXE__1st_chance_Process_Shut_Down__full_13d0_2009-12-06_00-33-14-734_0fd8.dmp]
User Mini Dump File with Full Memory: Only application data is available
Comment: '1st_chance_Process_Shut_Down_exception_in_CCNET.EXE_running_on_TEST218'
Symbol search path is: srvE:\symbolshttp://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Version 3790 (Service Pack 2) MP (2 procs) Free x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Machine Name:
Debug session time: Sun Dec 6 00:33:14.000 2009 (GMT+8)
System Uptime: 32 days 12:43:52.414
Process Uptime: 0 days 8:44:37.000
..........................WARNING: mscorjit overlaps mscoree
..............................WARNING: wldap32 overlaps dnsapi
..........WARNING: rasapi32 overlaps dnsapi
...WARNING: tapi32 overlaps rasapi32
.WARNING: rtutils overlaps rasman
..............WARNING: setupapi overlaps winsta
....wow64cpu!CpupSyscallStub+0x9:
00000000`78b842d9 c3 ret
why this happen?
Not related to CLR, instead it's 32-on-64 as described here http://www.dumpanalysis.org/blog/index.php/2007/09/11/crash-dump-analysis-patterns-part-26/ -- in short use the following:
.load wow64exts
.effmach x86
With those, kb and !analyze -v will give better results.
I hadve seen the same thing latly, I do not know for sure but it's probably some WOW64 artifact or possibly due to some more aggressive anti-exploitation techniques. At leat on Win32, even though the load address of a DLL may be different on occasion, if a DLL is mapped in antother process (like ntdll/kernel32) when your process start's if it is statically linking these DLL's also, it would always load at the same address until the next reboot.
It seems probable that more recent CLR exe's are able to remap various module's per-execution, I know that this is an issue on MSVC10 and Windows7 but perhaps it's been ported to additonal platforms for CLR applications.