Yesterday my system software got crashed on WINDOWS 2003 server. The Core shown below.
kernel32.dll!_RaiseException#16() + 0x3c bytes
rpcrt4.dll!_RpcpRaiseException#4() + 0x21 bytes
rpcrt4.dll!_NdrGetBuffer#12() - 0x1d3fe bytes
rpcrt4.dll!_NdrClientCall2() + 0x132 bytes
hnetcfg.dll!_FwOpenDynamicFwPort#16() + 0x1d bytes
hnetcfg.dll!_IcfOpenDynamicFwPort#12() + 0x6a bytes
mswsock.dll!_WSPBind#16() + 0xa55 bytes
ws2_32.dll!_bind#12() + 0x4e bytes
sal.dll!s_SktBind(s_Socket * sp=0x05943800, SAL_AddrBuf_t
* addrp=0x057cfe00,unsigned int addrsz=0x00000042) Line 76 + 0x14 bytes C++
sal.dll!SAL_SktBind(SAL_SktHandle_t * sh=0x05943800, SAL_AddrBuf_t
*addrp=0x057cfe00, unsigned int addrsz=0x00000042) Line 101 + 0xe bytes C++
Note: sal.dll is my software module. it is calling System Call bind() from our function SktBind()
Could you please tell, why it was crashed ? and how can I solve this problem.
If you have any comments or suggestion , please share with me.
The call to bind() from function s_SktBind() in sal.dll has caused the crash.
The first thing I would check is that you bind() is being called with proper arguments.
This doesn't look like kernel programming to me (re the tag).
Which process faulted? Looks like your program, since you have line number info.
What was the fault? AV? Or some other exception?
Paste the line and surrounding code that crashed. (Line 101 of the file that defines SAL_SktBind).
hnetcfg.dll is a process associated with Home Networking Configuration Manager from Microsoft Corporation.
Search Microsoft support for relevant articles (e.g. maybe this one)
The code that is the origin of the problem seems to be dealing with networking. Is this correct?
I don't think you have posted the full call stack, but sal.dll is a dll that is provided by Novell and this is from where the error originates. So you might want to check if a newer version of this dll is available.
Related
i have got the following issues.
I want to Read/Write on a Rfid-Tag and lock this block afterwards.
I have the following hardware:
AL1330, IFM Io-link Master https://www.ifm.com/mounting/80284123DE.pdf
DTI513, IFM IO-Link Rfid-REader/Writer https://www.ifm.com/mounting/11458695DE.pdf
Beckhoff, PLC CX5230
Rfid-Tag, ICode Slix, https://www.nxp.com/docs/en/data-sheet/SL2S2002_SL2S2102.pdf
I can read the Uid, can write and Read Data Bytes on the RFID.
I fail to lock the Block afterwards. I tried various ways with CoE Communication.
I divide the Problem into 3 steps:
Step 1:
Craft the CMD responsible for the Lock on the Tag.
This is specified in the responsible Norm
this are the Flags
This leads me for example to this Command
Step2 : Calculating the CRC
-For the CRC in the Norm there is one Example (CRC Iso/IEC 13239)
0x22 0x20 0x01 0x23 0x45 0x67 0x89 0xab 0x04 0xe0 0x0b
this command shall lead to CRC BAE3.
My Oscat Lib Block Basic.CRC_Gen with this Parameter returns this value
Same as http://www.sunshine2k.de/coding/javascript/crc/crc_js.html
With more testing, the crc calucaltions differ, and i do not know why and how,
and which one is correct.
Edit:
- More testing and i recognized, the Oscat Library FB Basic.CRC_Gen
fills any Input, shorter than 4 bytes, with 0x00.
- there should be the workaround, to use addressed commands with the optional Uid.
Step3:
Writing the Command with the appended CRC to Tag via CoE
- i use the Beckhoff FBs to access CoE
I can acces the different IDs with Subids and get Results,
so this works
i found the IO-Acyclic Command, which i think is the right one, to issue commands to
the tag
the docu in the AL1330 shows this
I tried a lot of different stuff, but cannot make it happen.
Problem is, i am not sure, if the CMD is correct or not, the CRC is wrong or how to make the Acyclic Command to work.
I tried for days and found no solution.
So i would be very glad for tips and hints in the right direction.
Thanks
I hope i do not violate any rules
I am interfacing SD card(16Gb Sandisk ultra micro SD) to STM32F407 micro-controller with SDIO protocol using chan FatFS library. When I try to write data into existing file, f_write returns FR_OK and returns numbers of written bytes(this value is equal to number of bytes to write), but f_close() returns FR_DISK_ERR, and in the end the file is empty.
With more experiment i found that if i format the micro SD card using 64Kb unit allocation size and the existing file with some text in it then i am able to write 64Kb data to file but f_close() returns FR_DISK_ERR, and in the end the file is not empty. I am able to see the data in Windows 10 OS.
If the existing file has no text in this then i am getting an empty file even though f_write is returning FR_OK but f_close is returning FR_DISK_ERR.
In short when I try to use f_write on a text file i created from my PC I can overwrite the content of that file till 64Kb. But i can't get it to work with an empty file i created with f_open
I came across a similar post with the same issue
TMS320F2812 FatFs f_write returns FR_DISK_ERR
I tried the solutions given in the above post but it didn't work. Since i have 192K RAM in my controller, i guess its sufficient enough for this FatFs module to work. My stack size is around 13Kb and Heap size 4Kb which is too much for this application. SD card is given 3.3V supply voltage.
I went little deep in code to see where the error is occurring and found that i am getting SD_ILLEGAL_CMD error while setting block size for card. Inside f_close(ff.c file)->f_sync(ff.c file)->move_window(ff.c file)->disk_read(diskio.c file)->SD_ReadBlock(sdcard.c file) is returning SD_ILLEGAL_CMD error while setting block size for card.
Any solutions are appreciated. If more information is required please feel free to ask, i will update with more information.
Chan FatFs Version - R0.07e
In an attempt to understand C memory alignment or whatever the term is (data structure alignment?), i'm trying to write code that results in a alignment error. The original reason that brought me to learning about this is that i'm writing data parsing code that reads binary data received over the network. The data contains some uint32s, uint64s, floats, and doubles, and i'd like to make sure they are never corrupted due to errors in my parsing code.
An unsuccessful attempt at causing some problem due to misalignment:
uint32_t integer = 1027;
uint8_t * pointer = (uint8_t *)&integer;
uint8_t * bytes = malloc(5);
bytes[0] = 23; // extra byte to misalign uint32_t data
bytes[1] = pointer[0];
bytes[2] = pointer[1];
bytes[3] = pointer[2];
bytes[4] = pointer[3];
uint32_t integer2 = *(uint32_t *)(bytes + 1);
printf("integer: %u\ninteger2: %u\n", integer, integer2);
On my machine both integers print out the same. (macbook pro with Intel 64 bit processor, not sure what exactly determines alignment behaviour, is it the architecture? or exact CPU model? or compiler maybe? i use Xcode so clang)
I guess my processor/machine/setup supports unaligned reads so it takes the above code without any problems.
What would a case where parsing of say an uint32_t would fail because of code not taking alignment in account? Is there a way to make it fail on a modern Intel 64 bit system? Or am i safe from alignment errors when using simple datatypes like integers and floats (no structs)?
Edit: If anyone's reading this later, i found a similar question with interesting info: Mis-aligned pointers on x86
Normally, the x86 architecture doesn't have alignment requirements [except for some SIMD instructions like movdqa).
However, since you're trying to write code to cause such an exception ...
There is an alignment check exception bit that can be set into the x86 flags register. If you turn in on, an unaligned access will generate an exception which will show up [under linux at least] as a bus error (i.e. SIGBUS)
See my answer here: any way to stop unaligned access from c++ standard library on x86_64? for details and some sample programs to generate an exception.
hw : lpc1549 eval board with usb hid test firmware ...
endpoint size 64 bytes
endpoint intr reads out-report buf and displays len and data in hex ...
copies out_report into in_report buf and echoes back with write funct and len
host :
using qt5 , libusb-1.0.19 wingw32 dll and hidapi code
hid test code issues all your api calls (except write and read) sucessfully in linux, win7 and win8.1
test code issues hid_write followed by hid_read and get's data back properly in linux
i am not using the, by hidapi hid_write mandatory flagged Report ID, since the nxp firmware and keil software do not use it (as far as i could figure out) ...
my linux sw sends and receives a defined 64 byte pattern or smaller len) correctly and byte [0] is part of this pattern ... out and in byte [0] data is intentionally different and correct received
running the keil hid client under windows succeeds to properly communicate with the lpc1549 firmware, even they only transfer and echo one byte ...
my firmware has the endpoint size changed to 64 bytes (i hope my changes are correct) and the keil hid client works with it in windows so my assumption is that my descriptors are correct ... hopefully
host sw kububtu 14.04
hid_write len = 17, device 17 bytes received, 17 bytes indicated as received ... all seems to work properly
host sw with hidapi in win 8.1
hid_write len = 17 bytes shows up on device with 16 bytes correct and the rest is 0, but the read indicates a received len of 64 ... i issued a write of 17, received 16 correctly, but was indicated as 64 received
also win 8.1 throws a blank system32/cmd prompt window up ... why ???
the same hangs on win7 and only a hid_write len = 0 succeeds ... popping the same cmd prompt ... received len = 64, but no data transferred (as it would make sense with len = 0)
i can not single step or breakpoints since qt debugger get's segment fault upon app loading
also i link in my qt app to the hidapi "windows/hid.c" code and it is now part my code
sorry for my rather complicated description
why is a Report ID mandatory if it's not being used ... it would be a waste of one byte and if uint32_t alignment is required it would be a waste of about 7 % of the 64 bytes data
why does the keil hid client written in c++ msvs work correctly with my fw and hidapi not
would the functioning of the keil hid client indicate that my fw and my descriptors and report len are correct
What would cause an empty cmd prompt popping up?
What could i be doing wrong (a whole hidapi based app is correctly communicating with a complete usb based firmware pgm, not just the described test code)?
after a couple of days a few things got clear
the ReportID seems to be something in windows and on the host side only ... the firmware is not effected on my setup
also what was not to clear initially is that the ReportID is in addition to the max of 64 report bytes
so i create a buffer with 1 + 64 bytes = 65 ... the 1st one is zero since i do not use the ReportID mechanism and the remaining 64 are normally used
the write call data size needs to be therefore 1 + whatever the reportsize is in the usb hid descriptor endpoint side
in linux there is no ReportID on hid what i could see
next : make sure the data length specified in the write call on the host as well on the device match exactly the endpoint size definitions, otherwise no data gets across either direction and your software might hang (wait forever) on the read on the other end
i hope this might help others to get a better pict of the windows end of the hidapi hid_write calls
Alan Ott wrote me the following
http://www.signal11.us/oss/hidapi/hidapi/doxygen/html/group__API.html#gad14ea48e440cf5066df87cc6488493af
There is always a report ID. You must always send a report ID in HIDAPI, but it will not be sent to the device if the report ID is 0.
I am a USB HID newbie and I am trying to use the HIDAPI for my application.
I have a question about using HIDAPI (in Visual Studio) regarding the report ID.
When I try to use the HIDAPI and connect to the Microchip Custom Demo,
I am confused about this aspect: The 65-byte report does not make sense to me!
Even if I don't want to set a report ID, I need to set the first byte to 0 and send the 65-byte buffer to the device, but I only receive 64 bytes of data from the Microchip device (because the report is 64 bytes long).
It looks like:
**Host** **Device**
*write_hid*
65 byte --------------->
*read_hid*
<------------------ 64byte
However, it seems weird to me.
Isn't the report that is sent or received always 64 bytes? Because the specifications say the report should have a 64-byte maximum and be sent every 1 ms.
If the answer is yes, why does the API maintain 65 bytes for 1-byte report ID?
Is the report ID contained in the 64 bytes?
The 65-byte data length does not make sense to me.
If your application does not include a Report ID in the HID descriptor, then there shouldn't be a Report ID prepended.
As you can see in the documentation of hid_write, HIDAPI should only send 64-bytes if the first byte is 0 (i.e. there is no Report ID):
unsigned char data[65];
buf[0] = 0; /* Single report */
// Fill report starting at buf[1]
hid_write(device, data, sizeof(data));
When looking at the source code for the libusb implementation, you can see that the Report ID is correctly stripped. On Windows however, the data is passed straight to Windows. I don't know Windows programming, but perhaps this makes a difference. Try testing this on Linux instead.