Here is my code:
#pragma comment (linker, "/INCLUDE:_tls_used")
#pragma comment (linker, "/INCLUDE:p_tls_callback1")
#pragma const_seg(push)
#pragma const_seg(".CRT$XLAAA")
EXTERN_C const PIMAGE_TLS_CALLBACK p_tls_callback1 = tls_start_protect;
#pragma const_seg(pop)
and following piece of code is directly called by tls_start_protect.
char buf[10];
sprintf_s(buf, 10, "hello\n");
and it crashes.
0:000> k
# Child-SP RetAddr Call Site
00 0000007c`e676eb58 00007ff6`e3b04829 AGTtest!__crtFlsGetValue+0x10 [f:\dd\vctools\crt\crtw32\misc\winapisupp.c # 422]
01 0000007c`e676eb60 00007ff6`e3b047f3 AGTtest!_getptd_noexit+0x1d [f:\dd\vctools\crt\crtw32\startup\tidtable.c # 277]
02 0000007c`e676eb90 00007ff6`e3b03737 AGTtest!_getptd+0xb [f:\dd\vctools\crt\crtw32\startup\tidtable.c # 337]
03 0000007c`e676ebc0 00007ff6`e3b06030 AGTtest!_LocaleUpdate::_LocaleUpdate+0x1b [f:\dd\vctools\crt\crtw32\h\setlocal.h # 248]
04 0000007c`e676ebf0 00007ff6`e3b02816 AGTtest!_output_s_l+0x6c [f:\dd\vctools\crt\crtw32\stdio\output.c # 1028]
05 0000007c`e676ef10 00007ff6`e3b028a8 AGTtest!_vsnprintf_helper+0x92 [f:\dd\vctools\crt\crtw32\stdio\vsprintf.c # 140]
06 0000007c`e676ef80 00007ff6`e3b025a3 AGTtest!_vsprintf_s_l+0x3c [f:\dd\vctools\crt\crtw32\stdio\vsprintf.c # 237]
07 0000007c`e676efc0 00007ff6`e3b0112f AGTtest!sprintf_s+0x1f [f:\dd\vctools\crt\crtw32\stdio\sprintf.c # 216]
08 0000007c`e676f000 00007ffb`bd6a52c8 AGTtest!tls_start_protect+0x1f [d:\repos\antidebug\agt\tls_callback.c # 83]
09 0000007c`e676f040 00007ffb`bd6a1577 ntdll!LdrpCallInitRoutine+0x4c
0a 0000007c`e676f0a0 00007ffb`bd7201cd ntdll!LdrpCallTlsInitializers+0x93
0b 0000007c`e676f120 00007ffb`bd75166d ntdll!LdrpInitializeProcess+0x1c99
0c 0000007c`e676f510 00007ffb`bd706d5e ntdll!_LdrpInitialize+0x4a8b9
0d 0000007c`e676f590 00000000`00000000 ntdll!LdrInitializeThunk+0xe
Similarly family of _vscprintf(format, args) also crash in __crtFlsGetValue.
I wonder it's too early to call family of printfs, before which, initialization haven't been done. What I know is that TLS callback(Only DLL_PROCESS_ATTACH) is executed after 'ntdll!Ldr*' load all dependent modules and before 'EOP'.
Question:
Any detail about the initialization of _vscprintf, is it done by "CRT" in some CPP constructors' code???
Any other restriction of TLS callback???
If I do need to call _vscprintf in TLS Callback, how? (somehow, I just wanna print before main)
you use static linked CRT - this is visible from your stack trace. static linked CRT in exe initialized after exe entry point is called. but tls callback on DLL_PROCESS_ATACH called before exe entry point. in this case your static CRT yet not initialized and any call to this CRT code can crash. solution - use dynamic linked CRT in separate DLL - in this case it already will be initialized before TLS callback
Related
I am trying to get CAN communication running via an external SBC (TLE9263) board.
Microcontroller: S32K312
Ext. SBC board: TLE9263_EVB_2
Without SBC, i.e., using a standard external CAN transceiver TJA1057GT, CAN communication is running.
With SBC, some messages are received once, but then the SBC transceiver goes down, and CANIF_E_FATAL Det error occurs (Call Stack).
I configured the SBC registers as follows: SBC registers configuration
The following values are observed on the SPI-MOSI signal:
41 00 - SUP_STAT_1
82 00 - HW_CTRL
81 1F - M_S_CTRL
84 07 - BUS_CTRL_1
85 00 - BUS_CTRL_2
83 82 - WD_CTRL
The above observed values are expected in my opinion. What could be the cause of communication not working?
Additionally (not sure if this is relevant), the Fail Output LEDs on the TLE9263 board, FO1 and FO3 are ON as soon as the board is powered, and FO2 is blinking, and this status of the LEDs remains the same when the software is run.
I am developing a program to connect my PC to Omron CJ2M PLC to send read / write commands.
As per my understanding, Omron PLCs can be communicated over 3 methods:
1) Hostlink,
2) FINS, (TCP or UDP) and
3) EIP.
My requirement here is to connect CJ2M through EIP, and send Read/Write commands over EIP(CIP) protocol.
Initally EIP communication needs to send 2 requests:
1) List Services and 2) Register Sessions
Register Sessions returns a handle which should be used in further communication over EIP.
I am successfully able to send List Services, Register Session and Forward Open (RR Data) and these are successfully replied by the Omron PLC. There is no problem in these 3 requests/responses.
Now I want to know which command/service need to be used to read the memory area of Omron (say DR 20 memory address).
I am sending service code 0x4d over RR Data, but it says "Vendor Specific Error" and then connection gets terminated.
I need protocol specification for Omron EIP or wireshark logs or some sniffed packets where a request / response is captured over EIP communication from PC to Omron PLC (no fins, no hostlink).
We can send requests to Omron EIP using "Send Unit Data" with service code 0x4d.
This service (0x4d) is used to send write request as per EIP documentation, but we can insert the Omron specific commands (FINS) to read the memory areas in command specific data.
0000 00 00 00 00 00 80 0e 00 01 00 80 00 02 00 00 00
0010 00 00 00 12 01 01 82 00 00 00 00 01
when I send an API ND command to a remote endpoint I get ???
When I send an API ND command from a VB program using the following packet;
7E 00 05 08 01 4E 44 00 64
I get;
7E 05 3F 14 E4 41 3F
Its a response -- but not as I know it. Neither the checksum "3F" or command length "05" are comprehensible to me. On the other hand if I wait for more bytes by setting "Serialport1.ReceivedBytesThreshold" (threshold: 10 bytes in buffer > event is fired) to 10 the "SerialPort1.ReadExisting()" statement times out. Any suggestions for decoding? Both coordinator and endpoint are XBEE PRO S2Bs.
I don't think it makes sense to send ATND as a remote AT command, and it will probably be ignored on the remote node, or trigger node discovery at that node with the responses staying local.
It looks like your response is possibly dropping null bytes (0x00), like the MSB of length, and one more in the packet itself. I'm not familiar with a frame type of 0x3F though -- is it documented for that XBee module you're using?
After a node discovery, you should see multiple AT Response frames (type 0x88?) come back over some time (based on ATNT, I believe), until you get one with a short payload (indicating discovery is complete).
In the SSL client, I am receiving a serverHello message with tampered message length like below.
"16 03 00 00 35 02 00 08 00... "
Here, "00 08 00" is message length which is coming as 2048 bytes. But in the next record, it sends "serverCertificate & serverHelloDone" messages.
So, in the client side, it waits to read 2048 bytes. but messages "serverHello, serverCertificate, serverHelloDone" are not having 2048 bytes combinedly. So, still client waits to read pending message (socket is blocking socket). So, it just waits in recv and never comes out.
I would like to know how applications should handle this situation. Is there any way in SSL protocol, we can identify this. If not possible, how applications should handle this situation to come out ?
Thank you !
Regards
Satish.
I'm trying to unmount a volume in my Cocoa application using the Disk Arbitration Framework.
Before calling:
DADiskUnmount(disk,
kDADiskUnmountOptionDefault,
unmountCallback,
self );
I register a callback function that get's called afterwards:
void unmountCallback(DADiskRef disk, DADissenterRef dissenter, void *context )
{
if (dissenter != NULL)
{
DAReturn ret = DADissenterGetStatus(dissenter);
switch (ret) {
case kDAReturnBusy:
printf("kDAReturnBusy\n");
break;
}
}
In this function I try to interpret the dissenter return value but get stuck. I suppose it should be of type DAReturn and have a value like kDAReturnBusy But when e.g. iTunes is using the volume and it can not be unmounted "ret" has a value of 0xc010 that I don't quite understand.
In case unmounting fails I'd like to find out why the volume can't be unmounted and in case another application is using it remind the user of closing this application.
But when e.g. iTunes is using the volume and it can not be unmounted "ret" has a value of 0xc010 that I don't quite understand.
The documentation you linked to, for the DAReturn type, lists all the Disk Arbitration constants as looking like this:
kDAReturnError = err_local | err_local_diskarbitration | 0x01, /* ( 0xF8DA0001 ) */
So, DA's error returns are all made of three components, OR'd together.
If you look at the documentation for DADissenterGetStatus, it says:
A BSD return code, if applicable, is encoded with unix_err().
If you then search the headers for unix_err, you find it in /usr/include/mach/error.h, which says:
/* unix errors get lumped into one subsystem */
#define unix_err(errno) (err_kern|err_sub(3)|errno)
and:
/*
* error number layout as follows:
*
* hi lo
* | system(6) | subsystem(12) | code(14) |
*/
There's those three components again. Some other macros in error.h arrange the system and subsystem values (e.g., err_kern and err_sub(3)) into those positions.
So now, let's open the Calculator, press ⌘3 to put it into programmer mode, switch it to base-16, and type in your error code, and see what it says:
0xC010
0000 0000 0000 0000 1100 0000 0001 0000
31 15 0
Breaking that apart according to the above layout, we find:
0000 00
31
System: 0, which error.h says is err_kern. This error came from the kernel.
00 0000 0000 11
31 15
Subsystem: 3 (0b11). This plus the system code matches the aforementioned definition of unix_err. So this is a BSD return code, as DADissenterGetStatus said.
00 0000 0001 0000
31 15 0
Individual error code: 16 (0x10, 0b10000).
UNIX/BSD errors are defined in <sys/errno.h>, which says:
#define EBUSY 16 /* Device / Resource busy */
This suggests to me that you can't unmount that device because it's in use.
the above post nicely explains how to find out information about the error code which you have seeing.
however, how to actually solve the issue with unmount failing due to EBUSY?
if you don't care about processes that might still be using the mounted volume, you can just force the dismount by changing:
DADiskUnmount(disk, kDADiskUnmountOptionDefault...)
to
DADiskUnmount(disk, kDADiskUnmountOptionForce...)
your idea of "reminding the user of closing this application" is more complicated to implement. if you really want to go that way, i guess you could parse the output of /usr/sbin/lsof to find the 'offending' process names